SOA is a fundamental shift from vertical to horizontal:
Was having a telephone conversation with a colleague today and the discussion was so good that I wanted to try to capture some thoughts we batted around for future pondering.
What impact does this shift bring? For example, it brings the SLA concept into mind because you have to htink about what has to go across rather than up and down. "I'm trying to use your thing not trying to build my own thing". How can you think about that at a mission level? Because a mission is built atop of or dependent to someone else's mission. Higher level capabilities are composed from other capabilities and value-add in the supply chain. This value-add can range from being strictly the combination of existing capabilities - i.e. bring together the three things that need to be combined in a single view - to bringing the knowledge/capability to bear to use all of those capabilities together in pursue of the mission objectives.
You have to think about the types of ways that people can use your capability/information. This is where the concept of SLA agreement comes into the play because it forces you to think about the flexibility that needs to be embodied in the interface so that data can be exposed as needed for a particular need as opposed to taking the fixed interface approach in which a data provider exposes data in one way and a potential consumer must take it as-is and filter through any portion of the data not needed for their particular purpose.
Friday, December 23, 2005
Tuesday, December 20, 2005
Metcalfe's Law and SOA
More and more I'm finding parallels between the concepts of SOA and technical and business ideas. I was planning on posting some comments that I have on Neal Stephenson's excellent essay "In the Beginning was the Command Line". I was introduced to the essay through an internal presentation made here at my company by D. Calvin Andrus a week or so before I left for the Vienna FTF meeting of the SOA Reference Model. Here's the blog connection: in this presentation, he discussed Wiki and Blogs as a technology incarnation that supports continuous learning and adaptation and complexity theory. One of the slides had a screen shot from his own blog, from 5 January 2005. This particular post focused on Neal Stephenson's essay. I was intrigued enough to print out a copy to read on the airplane ride over the Atlantic. I have several notes on the content on links between his ideas and my own ideas on Service Oriented Architecture. However, now that 2 weeks have passed, I needed to go back to the presentation to find the actual URL to his blog. Along the way, I saw another slide in the presentation focused on Metcalfe's Law and Disruption. It was speaking more of the role of 'link creation' in the development of new intellectual capital, but it prompted me to find out some more about Metcalfe's Law and think about how it relates to SOA. Along the way, I found an article by George Glidder titled "Metcalfe's Law and Legacy". This article states Metcalfe's law of the telecosm shows the magic of interconnections. Glidder goes on to demonstrate the power of potential connections not only in technology terms, but also in economic terms - for personal wealth as well as the creation of additional wealth in the economy. What's also interesting though, is that Metcalfe himself recognized that "In other words, it is the stations, rather than the network, that have to sort out and "switch" the messages." It goes on to state that while the concept of a figurative ether survives in modern communications, there isn't a literal ether that exists omnipresently to propagate communications - and dive into a discussion of ethernet and ATM.
One of the ideas that resonates well with me is that SOA is really about applying the lessons learned from the history of commerce to technology. I'll have to talk about that more later. Essentially, that's why I really appreciate articles and information that recognize SOA as more than the next wave of technology. But what I've now also started thinking about is what we can learn from what we already know.
So, how do we recognize that SOA isn't just about the potential connections that can be made - but just as much about the 'stations' or the players in SOA and how they uuse the interconnections? What does it mean 'to be about' when we talk about SOA? Heh, that's a topic to mull over another day - but it seems initially to be about the value, emergence and mindset of SOA. There's a relationship there between people, process, and infrastructure with the technology, but none of them stand alone; just like the interconnections themselves don't stand alone - nor have value alone.
I have also started thinking about the A in SOA - architecture and wondering if the way that SOA is typically approached is 'treating the ether as literal'? How does it change the approach to system architecture and design of a distributed system when the connections (and hence the network) isn't robustly connected always present entity?
So, these are my thoughts today. Unbaked as they are, I want to follow them through at some point.
One of the ideas that resonates well with me is that SOA is really about applying the lessons learned from the history of commerce to technology. I'll have to talk about that more later. Essentially, that's why I really appreciate articles and information that recognize SOA as more than the next wave of technology. But what I've now also started thinking about is what we can learn from what we already know.
So, how do we recognize that SOA isn't just about the potential connections that can be made - but just as much about the 'stations' or the players in SOA and how they uuse the interconnections? What does it mean 'to be about' when we talk about SOA? Heh, that's a topic to mull over another day - but it seems initially to be about the value, emergence and mindset of SOA. There's a relationship there between people, process, and infrastructure with the technology, but none of them stand alone; just like the interconnections themselves don't stand alone - nor have value alone.
I have also started thinking about the A in SOA - architecture and wondering if the way that SOA is typically approached is 'treating the ether as literal'? How does it change the approach to system architecture and design of a distributed system when the connections (and hence the network) isn't robustly connected always present entity?
So, these are my thoughts today. Unbaked as they are, I want to follow them through at some point.
Sunday, December 18, 2005
Successful SOA Reference Model meeting
Last week, I headed over to Vienna Austria to work with the SOA Reference Model TC to hopefully polish the working draft of the specification sufficiently that we can make committee draft by early next year. From where we started earlier this year until now, there has been a tremendous amount of thinking that has gone into Service Oriented Architecture. One of the biggest points of improvement last week was a reorganization of the material related to services. In simple words, these sections correspond to "What You Need" and "What You Do." Effectively, these sections of the specification explicitly call out and address both a static as well as dynamic nature to the understanding of 'service.' Essentially, earlier debates on whether service is an action or an object are just another way of expressing this duality.
When we started thinking about things in terms of duality, it quickly becomes apparent that the duality of static/dynamic is not the only duality - need and capability; potential and actual; business and technology are other examples that emerge.
The last idea: SOA is about business and technology together, is one that seems to be gaining momentum in the industry. Recently, XML.org cited an IBM whitepaper titled "IBM's SOA Foundation: An Architectural Introduction and Overview" that states, "SOA is about the business results that can be achieved from having better alignment between the business and IT." I agree, almost. Earlier, the statement is made that SOA is about aligning business with IT to make both more effective. Certainly itrecognizes the synergy that comes from treating business and IT as a duality. However, we need to remember that, when it comes right down to it, IT is a tool. Having spent considerable amount of time trying to isolate why the nuances of a single word clouded my understanding, I'd suggest that we think instead about SOA as "aligning IT to business" rather than the other way around.
When trying to clearly express what is different about service oriented architecture, SOA if you will, this explicit recognition of dualities becomes a clear way to think about the differences in the approach - and it is encouraging that many in the industry are converging on this same recognition
When we started thinking about things in terms of duality, it quickly becomes apparent that the duality of static/dynamic is not the only duality - need and capability; potential and actual; business and technology are other examples that emerge.
The last idea: SOA is about business and technology together, is one that seems to be gaining momentum in the industry. Recently, XML.org cited an IBM whitepaper titled "IBM's SOA Foundation: An Architectural Introduction and Overview" that states, "SOA is about the business results that can be achieved from having better alignment between the business and IT." I agree, almost. Earlier, the statement is made that SOA is about aligning business with IT to make both more effective. Certainly itrecognizes the synergy that comes from treating business and IT as a duality. However, we need to remember that, when it comes right down to it, IT is a tool. Having spent considerable amount of time trying to isolate why the nuances of a single word clouded my understanding, I'd suggest that we think instead about SOA as "aligning IT to business" rather than the other way around.
When trying to clearly express what is different about service oriented architecture, SOA if you will, this explicit recognition of dualities becomes a clear way to think about the differences in the approach - and it is encouraging that many in the industry are converging on this same recognition
Thursday, December 08, 2005
Working toward the SOA Reference Model
The SOA Reference Model TC is gearing up for the Face to Face meeting in Vienna Austria next week. The goal is to finalize the current working draft and elevate the draft to committee status by the end of the meeting. This is tremendous news because it means we are one step closer to a voluntary consensus standard that examines the key concepts and relationships between them for service oriented architecture - not product driven, not web service standards driven, not even software driven, but motivated to understand the essence of service and SOA.
I spent some time last night reading linguistic research to try and better understand what about the relationship between noun and verb forms of ‘service’ are sticking points for me. As I suspected; it has to with the implications about the relationships between these lexical forms. What was most interesting was to realize the variety of aspects to be considered. However, I think that I found what makes me want to tread careful and clearly understand and distinguish between service as a noun and service as a verb.
One of my colleagues, Chris Bashioum, used the wording 'the RM concept of service maps to a concrete "thing" called a service, that performs the action of bringing a desired capability to bear when invoked in the context of an SOA. This wording pointed out to me that there are two active portions of the ‘service scenario’:
1) That ‘of bringing a desired capability to bear’
2) That of the capability itself
Referring to a service as a concrete "thing" is essentially an abstract noun which performs the work of an active verb. Nominalization allows us write about a process or action and yet not mention who is involved. Again, this is part of the sticking point for me when it comes to a reference model in which we’re trying to unambiguously define key concepts – because we’re using terminology that permits us to unintentionally cloud the concepts when we are seeking clarity.
So I dug a bit further and discovered that there are many ‘types’ of nominalizations, including ‘episodic nominalizations.’ An episodic nominalization takes an active process and conceives it as a noun. So far so good, for service as both noun and verb. However, here’s where I found some interesting information about the intuition of language that is captured by these different forms. Although quite similar, these two forms represent adifferent semantics which conceptually develop. In an episodic nominalization, the conception is no longer viewed as a process but rather as a single episode (i.e. only as the sum rather than the sum of its parts). Yes this starts to get into cognitive psychology and linguistics ( and I apologize to those who just want to know what does the word service mean within the context of SOA but bear with me).
Where I got to is that yes, we may actually be talking about the same thing when we use service as an act and as an object - only we're looking at the concept from different angles. What I’m recognizing is that those angles come with specific inferences and assumptions that stem from language itself that we may not be explicitly aware of and which set up confusion.
So what am I saying? That the text in the draft works well to recognize that the term service(noun) unifies several related concepts – and we do it justice to recognize those interrelated concepts. Using the terminology above, they’re conceptualized into a single episode. If we are clear about that, then I’ll accept that a service can be intended as either.
I spent some time last night reading linguistic research to try and better understand what about the relationship between noun and verb forms of ‘service’ are sticking points for me. As I suspected; it has to with the implications about the relationships between these lexical forms. What was most interesting was to realize the variety of aspects to be considered. However, I think that I found what makes me want to tread careful and clearly understand and distinguish between service as a noun and service as a verb.
One of my colleagues, Chris Bashioum, used the wording 'the RM concept of service maps to a concrete "thing" called a service, that performs the action of bringing a desired capability to bear when invoked in the context of an SOA. This wording pointed out to me that there are two active portions of the ‘service scenario’:
1) That ‘of bringing a desired capability to bear’
2) That of the capability itself
Referring to a service as a concrete "thing" is essentially an abstract noun which performs the work of an active verb. Nominalization allows us write about a process or action and yet not mention who is involved. Again, this is part of the sticking point for me when it comes to a reference model in which we’re trying to unambiguously define key concepts – because we’re using terminology that permits us to unintentionally cloud the concepts when we are seeking clarity.
So I dug a bit further and discovered that there are many ‘types’ of nominalizations, including ‘episodic nominalizations.’ An episodic nominalization takes an active process and conceives it as a noun. So far so good, for service as both noun and verb. However, here’s where I found some interesting information about the intuition of language that is captured by these different forms. Although quite similar, these two forms represent adifferent semantics which conceptually develop. In an episodic nominalization, the conception is no longer viewed as a process but rather as a single episode (i.e. only as the sum rather than the sum of its parts). Yes this starts to get into cognitive psychology and linguistics ( and I apologize to those who just want to know what does the word service mean within the context of SOA but bear with me).
Where I got to is that yes, we may actually be talking about the same thing when we use service as an act and as an object - only we're looking at the concept from different angles. What I’m recognizing is that those angles come with specific inferences and assumptions that stem from language itself that we may not be explicitly aware of and which set up confusion.
So what am I saying? That the text in the draft works well to recognize that the term service(noun) unifies several related concepts – and we do it justice to recognize those interrelated concepts. Using the terminology above, they’re conceptualized into a single episode. If we are clear about that, then I’ll accept that a service can be intended as either.
Wednesday, December 07, 2005
The Definition of Service
Recall the definition I provided for the term service:
* A service is the performance of work for others.
In general, entities (people and organizations) create capabilities to solve or support a solution for the problems they face in the course of their business. I think it fair to say that some of these capabilities are core competencies. They might even create competitive advantages in the marketplace. SOA isn't fundamentally about creating new capabilities; it is about business services as the key organizing principles that drive the design of IT. What is the driver? Alignment with business needs.
So how does this tie back to definition of service? SOA is a way to organize the world around the concept of work performed for others. How is 'work' defined? By business needs. What world is organized? The performance of work, ostensibly implemented with IT assets. Notice I still express service as an act as opposed to an object. It is easy to think of a service as a thing (such as a web service). The difficulty with that approach is then differentiating between the capability (work performed) and the service. It also leaves unanswered chicken and egg questions like "if a service isn't invoked, does it exist" and "once interaction with a service is complete, does the service cease to exist" and " if there is no description of the service, is there a service"?
Ultimately, there are capabilities and there are needs. An example: let's say I have a catering company. You would like to have a dinner party catered. I offer my catering services for you. I perform the work of catering and you realize the benefit. The service is the act of me catering your party. I may describe the service beforehand in promotional materials (lets say); we most likely will negotiate and commit to a contract that establishs our shared expectations; and there will be an exchange of value - mostly likely because I will charge a fee for the service I offer.
Until I actually cater your dinner party, there is no service. There is potential for a service and an expectation of a service, but it boils down to the fact that the service is an act.
1) The concept of an offer in inherent to a service. On a notional timeline, if work is performed for others, there must be an offer to do so. It may be formal, it may be informal, it may be explicit, it may be implicit, it may not follow a publish-find-bind paradigm of offer. But an offer must be made by some entity that will perform the work. In general terms, I would say that an offer is a proposal which is made by some entity may so to address a need.
2) A specification is a description of the work/capability. Remember the definition considers the act . Therefore, the description focuses on interfaces and behavior to support interaction between two entities: one with a capability and one with a need.
3) Here is where most definitions of service within SOA go. I don't disagree that this is an important aspect to consider. However, I think that terming this concept 'service' is wrong.
I pulled these thoughts together as I mused a question on one of my earlier posts on the SOA-RM mailing list. Here's the text of my email:
"We seem to be starting to head back to the service as an object as opposed to an act. I still do not believe that a service is an ‘object.’ In fact, I believe that assumption has caused much of the difficulty in figuring out what a service actually is.
Right now, my best answer is: the implication is correct because is a service is an act, not an object, and we're again seeing a confuddling of ideas.
Ok. If anyone stumbles upon these initial posts, I'd love to hear addtional thoughts.
* A service is the performance of work for others.
In general, entities (people and organizations) create capabilities to solve or support a solution for the problems they face in the course of their business. I think it fair to say that some of these capabilities are core competencies. They might even create competitive advantages in the marketplace. SOA isn't fundamentally about creating new capabilities; it is about business services as the key organizing principles that drive the design of IT. What is the driver? Alignment with business needs.
So how does this tie back to definition of service? SOA is a way to organize the world around the concept of work performed for others. How is 'work' defined? By business needs. What world is organized? The performance of work, ostensibly implemented with IT assets. Notice I still express service as an act as opposed to an object. It is easy to think of a service as a thing (such as a web service). The difficulty with that approach is then differentiating between the capability (work performed) and the service. It also leaves unanswered chicken and egg questions like "if a service isn't invoked, does it exist" and "once interaction with a service is complete, does the service cease to exist" and " if there is no description of the service, is there a service"?
Ultimately, there are capabilities and there are needs. An example: let's say I have a catering company. You would like to have a dinner party catered. I offer my catering services for you. I perform the work of catering and you realize the benefit. The service is the act of me catering your party. I may describe the service beforehand in promotional materials (lets say); we most likely will negotiate and commit to a contract that establishs our shared expectations; and there will be an exchange of value - mostly likely because I will charge a fee for the service I offer.
Until I actually cater your dinner party, there is no service. There is potential for a service and an expectation of a service, but it boils down to the fact that the service is an act.
In general, my catering company offered a capability to serve or support a solution for someone else's problem. As such, I provide a service. My consumers have needs which may be satisfied by that capability.
Back the definition service within the context of SOA:
What I've seen and what I've read and what I've experienced is that service as a word is used as a unifier for the following related ideas:
1) The offer to perform work for others
2) The specification of the work offered for others
3) The software used as a tool to implement a capability performed for others
-as well as -
4) The performance of work for others
1) The concept of an offer in inherent to a service. On a notional timeline, if work is performed for others, there must be an offer to do so. It may be formal, it may be informal, it may be explicit, it may be implicit, it may not follow a publish-find-bind paradigm of offer. But an offer must be made by some entity that will perform the work. In general terms, I would say that an offer is a proposal which is made by some entity may so to address a need.
2) A specification is a description of the work/capability. Remember the definition considers the act . Therefore, the description focuses on interfaces and behavior to support interaction between two entities: one with a capability and one with a need.
3) Here is where most definitions of service within SOA go. I don't disagree that this is an important aspect to consider. However, I think that terming this concept 'service' is wrong.
I pulled these thoughts together as I mused a question on one of my earlier posts on the SOA-RM mailing list. Here's the text of my email:
"We seem to be starting to head back to the service as an object as opposed to an act. I still do not believe that a service is an ‘object.’ In fact, I believe that assumption has caused much of the difficulty in figuring out what a service actually is.
Right now, my best answer is: the implication is correct because is a service is an act, not an object, and we're again seeing a confuddling of ideas.
Ok. If anyone stumbles upon these initial posts, I'd love to hear addtional thoughts.
Initial Musing on SOA
So I've finally transitioned to the world of public blogging. I've culled so many good ideas from others blogs and wanted so many times to capture my thoughts on things service-oriented (or otherwise oriented) that I decided it is time to pony and start my own blog also.
Earlier this year, I stumbled upon Kim Cameron's original postings on the laws of identity. The discussion and debate was truly amazing to watch evolve. I've seen lots of posts about service -oriented , but have only of late begun to see things creeping in the direction that I believe heads toward the true power of the SOA concept (age old it is true - this really isn't an IT revolution but an IT realization).
For those of you that have followed the many discussions on the SOA Reference Model email list; we've been working for awhile now to tease out the essential definition of SOA, service and core concepts (i.e. a Reference Model). We also do this where I work too.
My goal is to revisit and discuss the many facets of the fascinating topic of SOA and I hope to spark some additional debate and ideas that will help further clarify ideas related to all things SOA. So let me state, in this first post, my view of SOA.
Fundamentally, service oriented architecture is an architectural paradigm. I'll borrow liberally from IEEE to state "SOA is the fundamental organization of a system,embodied in its capabilities, their interactions and the environment so that IT assets are aligned to business needs."
As a technologist, I often want to define the world in terms of things technical. Hence, it at first seems natural to define SOA in terms of an information system (whether distributed, centralized or other). However, the system that SOA references is actually much larger - it is the enterprise itself. This means there are necessarily technical and non-technical components to SOA. What it implies is that the value of SOA comes not from a new technology push, nor from a business process re-engineering, but the combination of technology and business value. This really is nothing new, but the mechanisms to experiment with the power of this concept are more readily now than they were before.
One of the other reasons that I wanted to begin to record my thoughts on SOA were the often repeated email exchanges I have with colleagues regarding the definition for 'service.' I mean, if SOA is a service-oriented architecture, should we have consensus on what a service is? Here's what can really open a can of worms. I don't believe a service is a thing. A service is an act.
A service is the performance of work for someone else.
Such a short definition that goes so against what my background in software tells me. I propose that we're struggling to reach consensus on the definition of service because I believe that we're trying to reach consensus on the wrong thing.
I'll leave this first post with that as food for thought and return to this shortly.
Earlier this year, I stumbled upon Kim Cameron's original postings on the laws of identity. The discussion and debate was truly amazing to watch evolve. I've seen lots of posts about service -oriented
For those of you that have followed the many discussions on the SOA Reference Model email list; we've been working for awhile now to tease out the essential definition of SOA, service and core concepts (i.e. a Reference Model). We also do this where I work too.
My goal is to revisit and discuss the many facets of the fascinating topic of SOA and I hope to spark some additional debate and ideas that will help further clarify ideas related to all things SOA. So let me state, in this first post, my view of SOA.
Fundamentally, service oriented architecture is an architectural paradigm. I'll borrow liberally from IEEE to state "SOA is the fundamental organization of a system,embodied in its capabilities, their interactions and the environment so that IT assets are aligned to business needs."
As a technologist, I often want to define the world in terms of things technical. Hence, it at first seems natural to define SOA in terms of an information system (whether distributed, centralized or other). However, the system that SOA references is actually much larger - it is the enterprise itself. This means there are necessarily technical and non-technical components to SOA. What it implies is that the value of SOA comes not from a new technology push, nor from a business process re-engineering, but the combination of technology and business value. This really is nothing new, but the mechanisms to experiment with the power of this concept are more readily now than they were before.
One of the other reasons that I wanted to begin to record my thoughts on SOA were the often repeated email exchanges I have with colleagues regarding the definition for 'service.' I mean, if SOA is a service-oriented architecture, should we have consensus on what a service is? Here's what can really open a can of worms. I don't believe a service is a thing. A service is an act.
A service is the performance of work for someone else.
Such a short definition that goes so against what my background in software tells me. I propose that we're struggling to reach consensus on the definition of service because I believe that we're trying to reach consensus on the wrong thing.
I'll leave this first post with that as food for thought and return to this shortly.
Subscribe to:
Posts (Atom)
