I was talking with a friend of mine today and he was making fun of the fact that I call myself an SOA Evangelist. He said there are some interesting anagrams for evangelist, so I had to go see. Here are some interesting ones that came up for SOA Evangelist:
Galvanise Toes
Navigates Loses
Nostalgia Eves
Salvation Gees
Envisage Altos
Negative Lasso
Gasolene Vista
Naivetes Goals
Loveseat Gains
Eating Salvoes (Cheers)
A Evangelist So (should be a question... A evangelist, so?)
A Negative Loss
A Navel Egoists
A Goat Evilness
Again Lose Vest
In particular I think the Naivetes Goal and Negative Lasso are particularly interesting.
Friday, August 01, 2008
Thursday, May 15, 2008
Intersection between Enterprise Architcture, ITIL and the SOA Movement
The past few weeks I have had an ephitheny about the relationship between ITIL and Enterprise Architecture. The relationships that the Enterprise Architecture bricks describe the information needed for a configuration item (CI) inside of the CMDB. That a CI has to have a type associated with it and that type should be a brick inside of EA.
How I came about this discovery is I was trying to figure out what are the CI for our application infrastructure. It seem to me that ITIL focused on the component aspect of things inside of the production environment. This usually consisted of things like physical devices and brought-in software. But the more I thought about that, it seemed as if something was missing. Bespoke (British for custom-made) software (stuff you build yourself) didn't seem to be as well covered.
So, it seemed as if the connection between the service provided and the hardware, software used were connected through some indirect way. However accurate, it seem something was missing.
Dr. Warner Vogel, CTO of Amazon, gave a speech on Enterprise Architecture where he indicated that Amazon was really a platform where buyers and sellers get together. The largest seller using the Amazon Platform was the Amazon Store. But when you think of Amazon, you have to think of the various domains that are interconnected. One domain is the platform which does things like provides services such as item management, buyer-centric human and systemic interfaces, seller-centric human and systemic interfaces, shopping cart management, promotions, advertiser-centric human and systemic interface, etc.
But there are other domains involved in the ecosystem. Front-end providers which sell through their interfaces items in the Amazon product set. Also, you have product providers (sellers) which offer their products and services as part of the Amazon product set. Another domain is the actual buyer who has their own process of purchasing a product that may connect to any of these sellers.
The point is that there are many intersections between these domains. That became significant to me in my quest for understanding. I asked myself, "What is really happening at these intersections." The answer I got was that control was being transferred.
In this diagram, you see that there is an interdependency between these domains. In particular, there are processes inside these domains that temporarily pass control (perhaps asynchronously) to the provider domain, which in turn can pass control, etc. When I thought about this harder, I came to the conclusion that there were two views into this intersection: the Interface and Interaction.
The interaction defines the reason for the intersection between the domain. Such as Request to purchase item or inquiry of books with "Amazon" in its title. An interface, however, is the actual connection between the domains. A "request to purchase item" can be connected to a consumer via multiple interface. There might be human or systemic. Said another way: the reason for the connection from the consumer process is the same regard of the method (interface) of connecting.
It was at this moment, that I realized that the domain boundary became critically important for sanity. So, that begged the question, "What is inside of the domain and what is outside?" and "What really is a domain?"
My conclusion is that a domain is an unit of authority that accomplishes work, orchestrates that work, provides and consumes services (collection of work) to other domains and manages exceptions, situations inside its sphere of control. Interactions specifically are what connect the processes (orchestrator) to other domains.
How I came about this discovery is I was trying to figure out what are the CI for our application infrastructure. It seem to me that ITIL focused on the component aspect of things inside of the production environment. This usually consisted of things like physical devices and brought-in software. But the more I thought about that, it seemed as if something was missing. Bespoke (British for custom-made) software (stuff you build yourself) didn't seem to be as well covered.
So, it seemed as if the connection between the service provided and the hardware, software used were connected through some indirect way. However accurate, it seem something was missing.
Dr. Warner Vogel, CTO of Amazon, gave a speech on Enterprise Architecture where he indicated that Amazon was really a platform where buyers and sellers get together. The largest seller using the Amazon Platform was the Amazon Store. But when you think of Amazon, you have to think of the various domains that are interconnected. One domain is the platform which does things like provides services such as item management, buyer-centric human and systemic interfaces, seller-centric human and systemic interfaces, shopping cart management, promotions, advertiser-centric human and systemic interface, etc.
But there are other domains involved in the ecosystem. Front-end providers which sell through their interfaces items in the Amazon product set. Also, you have product providers (sellers) which offer their products and services as part of the Amazon product set. Another domain is the actual buyer who has their own process of purchasing a product that may connect to any of these sellers.
The point is that there are many intersections between these domains. That became significant to me in my quest for understanding. I asked myself, "What is really happening at these intersections." The answer I got was that control was being transferred.
In this diagram, you see that there is an interdependency between these domains. In particular, there are processes inside these domains that temporarily pass control (perhaps asynchronously) to the provider domain, which in turn can pass control, etc. When I thought about this harder, I came to the conclusion that there were two views into this intersection: the Interface and Interaction.
The interaction defines the reason for the intersection between the domain. Such as Request to purchase item or inquiry of books with "Amazon" in its title. An interface, however, is the actual connection between the domains. A "request to purchase item" can be connected to a consumer via multiple interface. There might be human or systemic. Said another way: the reason for the connection from the consumer process is the same regard of the method (interface) of connecting.
It was at this moment, that I realized that the domain boundary became critically important for sanity. So, that begged the question, "What is inside of the domain and what is outside?" and "What really is a domain?"
My conclusion is that a domain is an unit of authority that accomplishes work, orchestrates that work, provides and consumes services (collection of work) to other domains and manages exceptions, situations inside its sphere of control. Interactions specifically are what connect the processes (orchestrator) to other domains.
Saturday, April 05, 2008
What does everyone keep considering WS-* as SOA?
I was reading Dana Gardner's blog on WOA will soon eclipse SOA as most impactful business transformation agent. I am confused why there is even a challenge.
Even at Gartner's Gartner Application Architecture, Development & Integration Summit Dec 2008 in Las Vegas had two men I highly respect Roy Schulte and Nick Gall (blog) had a point-counterpoint discussion about WS-* vs. REST. Although it was very fun to listen and participate, I believe that when statements about WOA replacing SOA doesn't seem to jive with me.
To me, SOA is more about take functionality and making it abstract, network-able and find-able. I believe that it's goal is to abstract functionality to the level that business people can understand and use it. That is why SOA is an incredible partner with Event Driven Architecture, BPM, BAM, Mash-ups, etc. When a business person (I would dare say the new "programmer") can understand the command of our new paradigm, productivity and effectiveness will go through the roof.
Perhaps the discussion focuses more around which is a better protocol for getting at the information. REST or WS-*. In that context, there is a lot of worthwhile debate. But I don't think an answer either way would make "WOA replace SOA" I think they are on different layers of abstraction.
I read a presentation of Nick Gall's (don't have the reference) and it said "We made software because hardware was too hard. Now software isn't soft enough. What is softer than software?" This is the problem I want to solve. I believe that the coordinated application of EDA (CEP), SOA, BPM, BAM in concert with a business awareness found in Enterprise Architecture will lead us down to the solution of Nick's challenge.
Even at Gartner's Gartner Application Architecture, Development & Integration Summit Dec 2008 in Las Vegas had two men I highly respect Roy Schulte and Nick Gall (blog) had a point-counterpoint discussion about WS-* vs. REST. Although it was very fun to listen and participate, I believe that when statements about WOA replacing SOA doesn't seem to jive with me.
To me, SOA is more about take functionality and making it abstract, network-able and find-able. I believe that it's goal is to abstract functionality to the level that business people can understand and use it. That is why SOA is an incredible partner with Event Driven Architecture, BPM, BAM, Mash-ups, etc. When a business person (I would dare say the new "programmer") can understand the command of our new paradigm, productivity and effectiveness will go through the roof.
Perhaps the discussion focuses more around which is a better protocol for getting at the information. REST or WS-*. In that context, there is a lot of worthwhile debate. But I don't think an answer either way would make "WOA replace SOA" I think they are on different layers of abstraction.
I read a presentation of Nick Gall's (don't have the reference) and it said "We made software because hardware was too hard. Now software isn't soft enough. What is softer than software?" This is the problem I want to solve. I believe that the coordinated application of EDA (CEP), SOA, BPM, BAM in concert with a business awareness found in Enterprise Architecture will lead us down to the solution of Nick's challenge.
Wednesday, February 06, 2008
NOREX State & Local Government Forum Speech
It's been a while since I blogged. I have let circumstances of life erode away the goal of writing 20 minutes a day. Thats not good! :)
Anyways, I was asked by a group called NOREX to lead off a forum on SOA. In order to better understand this, let me give a bit of background on NOREX. In essence they are facilitators. They have meetings and teleforums where they talk about technology without all the vendors pressing their individual goals.
I was told that most people attending this session would be still in the introduction or early implementation. This is my lead in for the SOA Teleforum. Hope it can benefit someone.
Jeff
What is SOA?
NOREX State & Local Government Forum
SOA Teleconference
As you know, SOA has been having a lot of hype lately and probably why we are discussion it today. SOA was coined by Gartner Analysts Roy Schulte and Yefim Natis and has been like gangbusters ever since.
But what is it? What is about this new “architectural style” that gets people excited and gets Gartner to say that by 2010, this style will be used in more than 80% of new mission-critical applications?
If we extend the Acronym, we get Service-Oriented Architecture. I’m sure you already realize that Service is the key word, but how does that apply. If you look at any other field, a service is something that is done for the benefit of another. You could look at this as an electrical or water service, or restaurant waiters or tax accountants. This definition is exactly what is meant by the service in service-oriented architecture. A piece of software that does something for another. However, all of the other examples have another thing in common: multiple consumers of their service or put another way, they were not created for the expressed purpose of one consumer. If we look at tax accountants, he or she follows the same set of rules, procedures, etc for every consumer that uses the service although each may take a different path inside the process based on individual circumstances. The tax accountant is consumer-agnostic. The service is not built for the needs of 1 consumer, but all or a large set of consumers. The Service as part of SOA is the same way. As an example, if we build a web-service that is designed to accept input from a single source, then it is not a service, but rather an API or Application Program Interface only.
So, let us take a look at the key principles an SOA must meet:
• Modular
• Loosely coupled
• Distributed or networked
• Contractual
• Consumer-agnostic
• Abstraction and understandable
Modular and loosely coupled are things that Computer Science professors kept drilling into our heads. The saying that I had to learn is “Maximize Cohesion while Minimize Coupling.” SOA enables both of these concepts. As an industry, we have been trying to get this going for a long time. In particular, modular programming, APIs, DLL, CORBA have all been trying to accomplish this goal. We are continuing the work.
Distributed or networked is very critical. A lot of the programs that have created over the years put the intelligence of the program deep inside. To understand this, think of a billing system or point of sales system. The functional piece of code that calculates sales tax is used over and over, but generally is buried deep inside of the code or accessible only via DLL or library. Distributed or Networked principle says that it has to be accessible via the network or more precisely that it is not loaded as part of the code base of the consumer as would be in a DLL or library.
Contractual principle is a very interesting one. Any real-world service has either an implied or explicit contract. When you drop your clothes off at the dry-cleaners, you determine a price via a chart; you choose a pickup based on rules; you choose starch and other options. The same thing applies with SOA. You have a contract that indicates what will be done, the functional and non-functional requirements, you indicate the semantic definitions.
Consumer-agnostic we discussed earlier, but in essence, you build a service for a large set of consumers not one consumer. That isn’t to say that you might not build something as version 1 to fit a single consumer and then increase its consumer-agnostic ability as we get into version 2,3 etc. This amount of this attribute is directly proportional to the ability to increase reuse.
I saved Abstract and understandable to last because it is the most important. In fact, I called SOA: Service-oriented Abstraction. Abstraction is the ability to make a complex item knowable. It allows us to conceptualize. It is this conceptualization that allows designers to use it. A computer example is the idea of a disk folder. There is a lot of complexity to being able to read and write to a disk drive. Years ago, device drivers were created that generalized this and made a common interface and then visual folders were created. So now we have only had to drop a file inside of a folder and the machine takes care of getting it written to the actual physical hard drive. Services allow the ability to abstract. The question is at what level of abstraction you build your services. We could build a service pretty low level and just make some functionality like save-to-disk or we could make our services higher level and make it something that the business user will be able to understand such as calculate sales tax or create order. By building higher level services, then we increase the opportunity to allow business users to be more actively involved and even to be building their own code.
As you can see, all of these principles build upon each other. It is the building that makes things
This presentation would be wrong if I didn’t at least say how we can use these services. Once we have built services, we need to figure out how to apply them. Obviously, we can use them inside of traditional application code. We can build applications that leverage services from other agencies or external entities. We could also use business process management (BPM) to define the business processes of our agency. By building higher level of abstraction services, business users can create or change their process to innovate. IT needs to be involved from assurance, testing, etc. perspective, but this will allow a better integration between the business and information technology.
Still other perspectives are web 2.0 concepts like mashups where people take functionality and data from different places and combine it in a new way. Perhaps by solving a problem that is high priority for them, but low priority for the enterprise.
You will notice that I never equated SOA with web services or REST or CORBA. I believe the concepts are not equivalent. The latter are transports or how I get it from here to there. But by using the principles I laid out, and then we will be pulling the functionality and data that are trapped in the bowels of our applications and bring it to the surface where we can build off of it and inter-collaborate better than ever before.
Anyways, I was asked by a group called NOREX to lead off a forum on SOA. In order to better understand this, let me give a bit of background on NOREX. In essence they are facilitators. They have meetings and teleforums where they talk about technology without all the vendors pressing their individual goals.
I was told that most people attending this session would be still in the introduction or early implementation. This is my lead in for the SOA Teleforum. Hope it can benefit someone.
Jeff
NOREX State & Local Government Forum
SOA Teleconference
As you know, SOA has been having a lot of hype lately and probably why we are discussion it today. SOA was coined by Gartner Analysts Roy Schulte and Yefim Natis and has been like gangbusters ever since.
But what is it? What is about this new “architectural style” that gets people excited and gets Gartner to say that by 2010, this style will be used in more than 80% of new mission-critical applications?
If we extend the Acronym, we get Service-Oriented Architecture. I’m sure you already realize that Service is the key word, but how does that apply. If you look at any other field, a service is something that is done for the benefit of another. You could look at this as an electrical or water service, or restaurant waiters or tax accountants. This definition is exactly what is meant by the service in service-oriented architecture. A piece of software that does something for another. However, all of the other examples have another thing in common: multiple consumers of their service or put another way, they were not created for the expressed purpose of one consumer. If we look at tax accountants, he or she follows the same set of rules, procedures, etc for every consumer that uses the service although each may take a different path inside the process based on individual circumstances. The tax accountant is consumer-agnostic. The service is not built for the needs of 1 consumer, but all or a large set of consumers. The Service as part of SOA is the same way. As an example, if we build a web-service that is designed to accept input from a single source, then it is not a service, but rather an API or Application Program Interface only.
So, let us take a look at the key principles an SOA must meet:
• Modular
• Loosely coupled
• Distributed or networked
• Contractual
• Consumer-agnostic
• Abstraction and understandable
Modular and loosely coupled are things that Computer Science professors kept drilling into our heads. The saying that I had to learn is “Maximize Cohesion while Minimize Coupling.” SOA enables both of these concepts. As an industry, we have been trying to get this going for a long time. In particular, modular programming, APIs, DLL, CORBA have all been trying to accomplish this goal. We are continuing the work.
Distributed or networked is very critical. A lot of the programs that have created over the years put the intelligence of the program deep inside. To understand this, think of a billing system or point of sales system. The functional piece of code that calculates sales tax is used over and over, but generally is buried deep inside of the code or accessible only via DLL or library. Distributed or Networked principle says that it has to be accessible via the network or more precisely that it is not loaded as part of the code base of the consumer as would be in a DLL or library.
Contractual principle is a very interesting one. Any real-world service has either an implied or explicit contract. When you drop your clothes off at the dry-cleaners, you determine a price via a chart; you choose a pickup based on rules; you choose starch and other options. The same thing applies with SOA. You have a contract that indicates what will be done, the functional and non-functional requirements, you indicate the semantic definitions.
Consumer-agnostic we discussed earlier, but in essence, you build a service for a large set of consumers not one consumer. That isn’t to say that you might not build something as version 1 to fit a single consumer and then increase its consumer-agnostic ability as we get into version 2,3 etc. This amount of this attribute is directly proportional to the ability to increase reuse.
I saved Abstract and understandable to last because it is the most important. In fact, I called SOA: Service-oriented Abstraction. Abstraction is the ability to make a complex item knowable. It allows us to conceptualize. It is this conceptualization that allows designers to use it. A computer example is the idea of a disk folder. There is a lot of complexity to being able to read and write to a disk drive. Years ago, device drivers were created that generalized this and made a common interface and then visual folders were created. So now we have only had to drop a file inside of a folder and the machine takes care of getting it written to the actual physical hard drive. Services allow the ability to abstract. The question is at what level of abstraction you build your services. We could build a service pretty low level and just make some functionality like save-to-disk or we could make our services higher level and make it something that the business user will be able to understand such as calculate sales tax or create order. By building higher level services, then we increase the opportunity to allow business users to be more actively involved and even to be building their own code.
As you can see, all of these principles build upon each other. It is the building that makes things
This presentation would be wrong if I didn’t at least say how we can use these services. Once we have built services, we need to figure out how to apply them. Obviously, we can use them inside of traditional application code. We can build applications that leverage services from other agencies or external entities. We could also use business process management (BPM) to define the business processes of our agency. By building higher level of abstraction services, business users can create or change their process to innovate. IT needs to be involved from assurance, testing, etc. perspective, but this will allow a better integration between the business and information technology.
Still other perspectives are web 2.0 concepts like mashups where people take functionality and data from different places and combine it in a new way. Perhaps by solving a problem that is high priority for them, but low priority for the enterprise.
You will notice that I never equated SOA with web services or REST or CORBA. I believe the concepts are not equivalent. The latter are transports or how I get it from here to there. But by using the principles I laid out, and then we will be pulling the functionality and data that are trapped in the bowels of our applications and bring it to the surface where we can build off of it and inter-collaborate better than ever before.
Monday, April 02, 2007
Services Contract
- Header
- Name: - The name of the service. Should indicate in general terms what it does, but not be the only definition
- Version - The version of this service contract
- RASI Attributes
- Responsible: Refers to the person(s) responsible for the deliverables produced — the "executor(s)." They're typically SOA project leaders, such as CIOs or enterprise architects
- Accountable: Characterizes the person who has the ultimate decision-making authority the "overseer."
- Consulted: Refers to the person(s) who must be consulted before action is taken. This is a two-way communication and occurs before an activity is completed.
- Informed: Characterizes those who should be informed that a decision or action is being taken. This is a one-way communication and may occur after an activity has been completed.
- Type - This is the type of service to help distinguish the layer it resides.
- Data
- Process
- Functionality
- Presentation
- Name: - The name of the service. Should indicate in general terms what it does, but not be the only definition
- Functional
- Functional Requirement - Indicates the functionality in specific bulleted items what exactly this service accomplishes
- Service Operations
- Infrastructure
- Invocation - Indicates the invocation means of the service. This includes the URL, interface
- SOAP
- REST
- Events Triggers
- Non-Functional
- Security Constraints - Defines who can execute this service in terms of roles or individual partners, etc.
- Quality of Service -Determines the allowable failure rate
- Transactional
- Service Level Agreement - Determines the amount of latency the service is allowed to have to perform its actions<
- Semantics - Dictates or defines the meaning of terms used in the description and interfaces of the service
- Process, if applicable - Describes the process, if any, of the contracted service
Friday, March 30, 2007
Contract-First Development of Services
Contract-First development of services will help companies move towards a service oriented architecture (SOA). When you can abstract code into services, it makes it easier to use those services as pieces and plug them into where ever they might be needed. By first building the service's contract, it provides the structure to define and make those pieces work together.
However, what IS a service? Some might say "it's a web service" or "It is creating modular, reusable code." It is true that the web service standards are important and re-usability is an important attribute. However, by taking the view that a service in an SOA is more similar to a lawn service than a web service helps debunk the notion that services are simply code that can be easily called from anywhere (Modularity). Instead, it allows us to consider that a service as a stand alone piece of functionality.
When you hire a traditional service such as a lawn service, the first thing that occurs is an agreement as to what will be done. The elements of this agreement include the name of what will be done, what the customer has to provide and what the end result will be. The agreement will also include performance and response time criteria. In the end, as a consumer, I don't generally care if my lawn care provider cuts my grass with a 20k dollar mower or a push power or a pair of scissors. The implementation is up to the provider, SO LONG as it is implemented meeting the agreement. We call this agreement a contract.
Services found in an SOA also need this type of agreement. A service contract includes both functional and non-functional requirements. The functional requirements include what the service does, the service interface and the means of invocation. the non-functional requirements include service level agreement, security and quality of service, transactional constraints, process and semantic definitions.
You might ask, "Why do I need this contract? What does it provide for me? Can't I just use the interface?" The reason you need it is to give the service it's own scope of responsibility. A basic tenet of SOA is that a service is an autonomous unit of functionality. Also, it provides a definitive scope of what that service need to provide. A contract increases visibility and provides a neat package of functionality that can be used as a component in our application infrastructure.
Another advantage in knowing the functional requirements is that before the code is even created, test cases can be developed to determine if the services performs the required functionality within the constraints of the contract. Some call this test-driven development.
Stability of the system is critical when you create a SOA. This stability is improved by the versioning of ontracts. Once a contract is established, it can not be changed and it must be supported as long as consumers exist for it. However, new versions can be cloned and modified. By having both versions of the contract supported, new functionality can be built and made available to early adopters while the old contract is still supporting other applications. This allows a company to be agile in reacting to business changes while not breaking existing applications.
Lastly, the contract should state ownership and responsibility matrix. This is in the form of who is involved as well as who is responsible for the evolution of the service. The RACI is a great starting place to show these stakeholders. RACI stands for Responsible, Accountable, Consulted and Informed. I have always had an issue between Responsible and Accountable. They seem very similar. So lets do the easy ones first.
Consulted represents the set of people who have input in to the contract. They are typically the main consumers or business subject matter experts. The important part is that this is a two way communication. Informed are the set of people who need to know about changes or the development of the contract, but do not have a voice in its creation. This is a one-way communcation.
Now for the difference between Responsible and Accountable. Responsible to me is the person who owns the problem or, hopefully, owns the vision. Accountable seems to be the person who has to approve it. One variation that I like more for the 'A' is assists. Who assists the Reponsible (Visionary/Owner) in making the vision a reality.
However, what IS a service? Some might say "it's a web service" or "It is creating modular, reusable code." It is true that the web service standards are important and re-usability is an important attribute. However, by taking the view that a service in an SOA is more similar to a lawn service than a web service helps debunk the notion that services are simply code that can be easily called from anywhere (Modularity). Instead, it allows us to consider that a service as a stand alone piece of functionality.
When you hire a traditional service such as a lawn service, the first thing that occurs is an agreement as to what will be done. The elements of this agreement include the name of what will be done, what the customer has to provide and what the end result will be. The agreement will also include performance and response time criteria. In the end, as a consumer, I don't generally care if my lawn care provider cuts my grass with a 20k dollar mower or a push power or a pair of scissors. The implementation is up to the provider, SO LONG as it is implemented meeting the agreement. We call this agreement a contract.
Services found in an SOA also need this type of agreement. A service contract includes both functional and non-functional requirements. The functional requirements include what the service does, the service interface and the means of invocation. the non-functional requirements include service level agreement, security and quality of service, transactional constraints, process and semantic definitions.
You might ask, "Why do I need this contract? What does it provide for me? Can't I just use the interface?" The reason you need it is to give the service it's own scope of responsibility. A basic tenet of SOA is that a service is an autonomous unit of functionality. Also, it provides a definitive scope of what that service need to provide. A contract increases visibility and provides a neat package of functionality that can be used as a component in our application infrastructure.
Another advantage in knowing the functional requirements is that before the code is even created, test cases can be developed to determine if the services performs the required functionality within the constraints of the contract. Some call this test-driven development.
Stability of the system is critical when you create a SOA. This stability is improved by the versioning of ontracts. Once a contract is established, it can not be changed and it must be supported as long as consumers exist for it. However, new versions can be cloned and modified. By having both versions of the contract supported, new functionality can be built and made available to early adopters while the old contract is still supporting other applications. This allows a company to be agile in reacting to business changes while not breaking existing applications.
Lastly, the contract should state ownership and responsibility matrix. This is in the form of who is involved as well as who is responsible for the evolution of the service. The RACI is a great starting place to show these stakeholders. RACI stands for Responsible, Accountable, Consulted and Informed. I have always had an issue between Responsible and Accountable. They seem very similar. So lets do the easy ones first.
Consulted represents the set of people who have input in to the contract. They are typically the main consumers or business subject matter experts. The important part is that this is a two way communication. Informed are the set of people who need to know about changes or the development of the contract, but do not have a voice in its creation. This is a one-way communcation.
Now for the difference between Responsible and Accountable. Responsible to me is the person who owns the problem or, hopefully, owns the vision. Accountable seems to be the person who has to approve it. One variation that I like more for the 'A' is assists. Who assists the Reponsible (Visionary/Owner) in making the vision a reality.
Friday, March 23, 2007
Assemble-to-order: How using it can improve agility and operational alignment
In manufacturing, there are several categories of production. A manufacture can be a "build-to-order", "engineer-to-order" or "assemble-to-order" shop. Engineer and build-to-order means they make their products from scratch or raw materials. This is the most flexible, but requires a longer lead time to make the final product and therefore is less agile. Assemble-to-order means that themanufacture take parts called assemblies, put them together in different interesting ways to create the mered of potential final products and thereby increasing agility. An example of this would be Dell Computer. When they take your order, they have lists of options for each area or functionality. These areas would include disk drive, motherboard, ram, operating system, monitor, etc. This ability allows Dell's customer to mix and match their system based on their needs.
Service Oriented Architecture gives IT shops the same advantage to their customers. By design, SOA helps engender the "assemble-to-order" mentality that is needed in order to become agile. In these terms, an SOA service is functionality. It abstracts or hides the complexity of "how to do something." So, this service is the equivalent to the assembly part in the manufacturing process.
IT shops have to decide on how to get these assemblies or functionality and what are the assemblies they need. The ability to make these decisions separates the successful implementers of SOA from the frustrated. Answering the how question better allows more agility. Answering the what question better allows more organizational alignment. Let's focus in on both.
The how decision affects agility because of resource allocation issues. With unlimited budget, talent and time, we would build everything from scratch because it specifically addresses our issues. Since this isn't the condition we live in, we have to decide what we build based on things that will make a difference for us in the marketplace and things that we have thecompetency to build. We need to allow others (3rd Parties) to build things that don't make difference for us or that we don't have the competency to build. A rule of thumb is from Anne Lapkin of Gartner , "Build for competitive advantage; buy or reuse for competitive parity." The beauty of this principle is that not only does it limit what you build, but also indicates who you should hire.
As we increase our understanding of the functionality needed to enable business processes, the more IT can serve the organization as a whole. Business are in essence a collection of processes, ideas and effort. Processes are broken into steps. Each of these steps is a function. An action to be taken. To help define the set of functional steps, an enterprise should develop a vocabulary. (There will be further blogs about vocabulary)
In the beginning, it may seem to have a lot of overlap and confusion as to what is a service. How granular to make the service. The rule is to make it large enough so that a typical person who deals with that process can understand what is happening but no more than that. This is what I am referring to as the Middle Ground between the Business and Information Technology. This is the chasm where chaos rules in today's business and IT integration. Semantics, language, comprehension of processes from differentvantage points all lead to this ineffective integration.
It is this chasm which causes a lot of the confusion. But it is also the place of the richest gains in productivity can be gained. I am not saying that to tackle all of the middle ground issue at once, but once familiar with the tools and how to use them is achieved, find an important but not mission critical process that lives in this middle ground to work on first. Use enterprise architecture vocabulary to name and describe the steps for the process. Then build, buy or reuse the services named according to the Build-Buy principle.
An important note to remember is that there may be more granular services that your higher level services use. The services in the middle ground are the ones that need to be understandable to the typical business person using that process.
Monday, February 05, 2007
Enterprise Nervous System
The Enterprise Nervous System (ENS) is an allegory to the human body. In the human body, there are two methods of reactions to various stimuli and situations: Conscience and sub-conscience. In this blog, I will attempt to bring together these thoughts and hopefully help make sense as to how events are the signals of the Enterprise Nervous System.
In conscience reactions, the brain determines a course of action based on its interpretation of the stimuli & situations and causes actions to occur directly. In sub-conscience reactions, the actions happen as part of conditioning or reflexes.
I would argue that systems that require a lot of human decisions have a higher conscience quotient which allows for thought before action, but reduces the responsiveness. Systems that are conditioned to respond in a certain way are more like sub-conscience reactions. They have the ability to quickly react to a situation without "thinking" about it.
As we have learned from Six Sigma techniques and process improvement efforts, there is value in conditioning responses. In particular, processes that are rote or have a preplanned responses should be developed using techniques that maximize this responsiveness. These would include using triggers for processes or business rules engines to make decisions. As they are reacting, they will execute services or "the muscle" of the Enterprise IT body.
However, not all responses can be or should be developed as automatic. In particular, innovations either by the company itself or its competitors can not necessarily be anticipated. These situations require the brain power of the Enterprise to work through how do/should we exploit or defend against the opportunity or threat that is reveled. This may require developing new muscles (services) or changing how the automatic reactions are occurring.
The goal should not be to automate everything for automation sake. The goal should be reduce the load placed on the conscience or thinking parts of the organization by creating conditioned responses to familiar or routine stimuli to free it to concentrate on non-routine and extraordinary situations.
Events are critical to this endeavor. Events carry the context and particulars of what has happened. When the event is something that we can in the sub-conscience sense, it is handled. If not, it should be escalated to the attention of the brain through a variety of tools. Business Activity Monitoring (BAM) and Complex Event Processing (CEP) are two of these mechanisms.
CEP allows events to be combined to infer other more complicated events. BAM allows trends and metrics to help determine when a situation changes. It is this change in the "State of the World" or significant event which typically need the attention of the Enterprise Conscience mind. It is important to note that these engines job is not to solve the problem, but rather to find the needles in the haystack that need attention.
Thursday, May 04, 2006
The Attributes of the Architecture
As promised, I hope to reduce some of the confusion of all of the names used in what I refer to as "the SOA Movement." Some of these terms are Event Driven Architecture (EDA), Service Oriented Architecture (SOA), Business Process Management (BPM), Business Activity Monitoring (BAM), Complex Event Processing (CEP) and many others.
First off, all of these things have different purposes. In the course of this blog, I will try to reduce the confusion. I hope that you will help me with comment and pepper me with questions.
Over time, you will see that my perspective of this subject tends to be a little different than what a lot of people are posting now. I believe that inherrently there is a new programming language being developed. A programming language where services are the commands, portals, business process management and integration suites are the logic or flow of the language. And the audience is not the computer science major, but rather the business major.
My philosophy of Service Oriented Abstraction is that our purpose is to allow us to:
As promised, I hope to reduce some of the confusion of all of the names used in what I refer to as "the SOA Movement." Some of these terms are Event Driven Architecture (EDA), Service Oriented Architecture (SOA), Business Process Management (BPM), Business Activity Monitoring (BAM), Complex Event Processing (CEP) and many others.
First off, all of these things have different purposes. In the course of this blog, I will try to reduce the confusion. I hope that you will help me with comment and pepper me with questions.
Over time, you will see that my perspective of this subject tends to be a little different than what a lot of people are posting now. I believe that inherrently there is a new programming language being developed. A programming language where services are the commands, portals, business process management and integration suites are the logic or flow of the language. And the audience is not the computer science major, but rather the business major.
My philosophy of Service Oriented Abstraction is that our purpose is to allow us to:
Separate the Complexities of Business Processes or What we do
From the Complexities of Data Manipulation or Functionality or How we do it
From the Complexities of Data or Things we do it to
Subscribe to:
Posts (Atom)