Governance and Service Orchestration/Workflow
During the 'Delivery Days' presentations on SOA today, Todd was able to condense the message of SOA into a single hour presentation. Very admirable attempt, however, 2 tenants of SOA were not identified as fundamental. So, my Ninja senses tell me to cover these two tenants (Governance and Service Orchestration/Workflow) so that his efforts to not go in vain. I know they were probably just missed because of time constraints.
Governance
All the plans of mice and men are doomed to failure unless someone is willing to execute the plans. Governance is just that. We have a plan to reuse and we say we will, but we never really expand this beyond individual project boundaries because of the autonomous nature of the business units, amongst other reasons. In any case, what mechanisms are in place to ensure governance? Is the Uuber BA and/or an Enterprise Architect within our clients organizations participating on reviews to ensure all the projects are sharing appropriately? Using Registries? Paying homage to the SOA Integration Ninja? How do we ensure vendors follow the rules when we bound them to fixed price contracts with little room for the extra work necessary to understand an environment? Well, we have the means and the technical tools to make amazing leaps in enterprise system connectivity and real value from composite applications, but unless you have the rigor to execute the plan and enforce governance, you will not reap the benefits proposed by SOA. This may not upset you, or your client, because all you both want to do is use the latest buzzword to sell your current initiatives. I know about you. Shame.
Service Orchestration/Workflow
As much as I believe Todd when he makes the ascertation that the Service registry is key to delivering long term benefits from SOA, where this reuse occurs is debatable. Since I like a good debate (non violent but severe) I will take up the challenge. The prospect of having a toolkit of services, which are composible into business processes and controlled through easy to change metadata, is utopian. However, the ideal to remove IT (Developers) from the picture, unless building new services, is not an unattainable goal. Tools exists that allow services to be represented within easy to comprehend workflow models (UML Activity Diagrams) some based on BPEL and whatnot but this value proposition is not about the use of standards like BPEL and BPMN, although important, it is the change in responsibility from IT People to the Business People for Orchestrating their services to meet the ever changing needs of THEIR business. This is certainly not unachievable since several of our clients are combining ESBs and Workflow products like POSSE, K2 and Lombardi to empower the Uuber BAs with not only a design time model of the business but a working production sandbox where the business can orchestrate, change, monitor and manage workflow ALL through metadata that effects the runtime behavior of underlying services. The reuse is present in this arena, allowing the business to reuse Master Data Reference services for validations and call string together individual services, such as: “Add a New User”, “Record Production Volume”, “Send Latency Notice”, “Generate Earnings Report”, for example, many times within multiple Workflows (jobs). Each would run somewhat differently, controlled by the business modifying the metadata to tweak the service to behave in an altered manner. Decision points and enterprise business logic would be reflected in the emerging/running models and even the panacea of BAM (business activity monitory) is possible using this platform since you can visualize where each workflow is by using the same model representation.
Whoops – rambled on their for a bit. So, time to sign off. On a final note, I was very pleased with the presentation made by Todd today. Just add these few addendum items (2 additional tenants covered above) and his material was bang on. Oh yes, and the business granularity of slide 11 or 12 is suspect. You know, the interfaces for the critical service contracts should be business related as opposed to algorithmic since they are being built for eventual orchestration by the now famous Uuber BA in his Workflow tool of choice J
I hope you enjoyed the rare presence of the SOA Integration Ninja himself, at today’s Delivery Day in Calgary. It was my genuine honor to be able to participate. Thank you. If you were not able to attend, the Integration presentation is posted to the Online Sharepoint site under SOA/Integration under the subtopic ‘Goals and Objectives’, I think. If you want it, you will find it dude.
Truth is only evident to the believer.
Murray Laatsch
The SOA Integration Ninja
Governance
All the plans of mice and men are doomed to failure unless someone is willing to execute the plans. Governance is just that. We have a plan to reuse and we say we will, but we never really expand this beyond individual project boundaries because of the autonomous nature of the business units, amongst other reasons. In any case, what mechanisms are in place to ensure governance? Is the Uuber BA and/or an Enterprise Architect within our clients organizations participating on reviews to ensure all the projects are sharing appropriately? Using Registries? Paying homage to the SOA Integration Ninja? How do we ensure vendors follow the rules when we bound them to fixed price contracts with little room for the extra work necessary to understand an environment? Well, we have the means and the technical tools to make amazing leaps in enterprise system connectivity and real value from composite applications, but unless you have the rigor to execute the plan and enforce governance, you will not reap the benefits proposed by SOA. This may not upset you, or your client, because all you both want to do is use the latest buzzword to sell your current initiatives. I know about you. Shame.
Service Orchestration/Workflow
As much as I believe Todd when he makes the ascertation that the Service registry is key to delivering long term benefits from SOA, where this reuse occurs is debatable. Since I like a good debate (non violent but severe) I will take up the challenge. The prospect of having a toolkit of services, which are composible into business processes and controlled through easy to change metadata, is utopian. However, the ideal to remove IT (Developers) from the picture, unless building new services, is not an unattainable goal. Tools exists that allow services to be represented within easy to comprehend workflow models (UML Activity Diagrams) some based on BPEL and whatnot but this value proposition is not about the use of standards like BPEL and BPMN, although important, it is the change in responsibility from IT People to the Business People for Orchestrating their services to meet the ever changing needs of THEIR business. This is certainly not unachievable since several of our clients are combining ESBs and Workflow products like POSSE, K2 and Lombardi to empower the Uuber BAs with not only a design time model of the business but a working production sandbox where the business can orchestrate, change, monitor and manage workflow ALL through metadata that effects the runtime behavior of underlying services. The reuse is present in this arena, allowing the business to reuse Master Data Reference services for validations and call string together individual services, such as: “Add a New User”, “Record Production Volume”, “Send Latency Notice”, “Generate Earnings Report”, for example, many times within multiple Workflows (jobs). Each would run somewhat differently, controlled by the business modifying the metadata to tweak the service to behave in an altered manner. Decision points and enterprise business logic would be reflected in the emerging/running models and even the panacea of BAM (business activity monitory) is possible using this platform since you can visualize where each workflow is by using the same model representation.
Whoops – rambled on their for a bit. So, time to sign off. On a final note, I was very pleased with the presentation made by Todd today. Just add these few addendum items (2 additional tenants covered above) and his material was bang on. Oh yes, and the business granularity of slide 11 or 12 is suspect. You know, the interfaces for the critical service contracts should be business related as opposed to algorithmic since they are being built for eventual orchestration by the now famous Uuber BA in his Workflow tool of choice J
I hope you enjoyed the rare presence of the SOA Integration Ninja himself, at today’s Delivery Day in Calgary. It was my genuine honor to be able to participate. Thank you. If you were not able to attend, the Integration presentation is posted to the Online Sharepoint site under SOA/Integration under the subtopic ‘Goals and Objectives’, I think. If you want it, you will find it dude.
Truth is only evident to the believer.
Murray Laatsch
The SOA Integration Ninja
posted by Murray Laatsch at 8:44 PM
0 Comments:
Post a Comment
<< Home