When a customer or prospect inquires about a product or service we call this a "lead". Typically the information given in the initial call is not enough to understand what the customer hoped to achieve. Therefore it is necessary to go back and talk to them about their goals and plans. Today, modern software enables this process. For instance, if you go to the MomentumSI web site, I know you visited within 30 seconds. Via our web marketing automation system (and a network of cookies), I am informed about visits.
A similar system is needed in the SOA world. The SOA registry / repository must be viewed first and foremost as a shopping catalog and should employ modern techniques for capturing visits, searches and users. The service librarian must view all hits to the catalog as "leads". The process of following up on these leads is considered "Service Lead Management".
Here is a sample follow up
- Who are you? What department? What project?
- What kind of service were you looking for? (let me help you look)
- Do you want me to tell you more about Service X? (you found one)
- We don't have Service X. Do you want me to talk to the Service Portfolio Manager about adding one to the Shared Services Group?
- etc.
Remember, when you first get your Service Catalog going, it will be EMPTY. The goal is to find out what people need and to determine if they are good candidates for shared services. Kill "Empty Registry Syndrome"!
Monday, June 25, 2007
Monday, June 18, 2007
Using the Zachmann Framework to Manage Schneider Oriented Architecture
If you haven't seen Bill Zachmann's attempt to throw water on the SOA fire, it is worth a read.
Bill basically says that SOA has been overhyped, is the same-ole architecture and that it is like CORBA, etc. He goes on to say that the new thing is XML and you can already do that in Microsoft .Net. He also states that, " SOA is a matter of good, modular, object-oriented design..." No Bill, SOA is a matter of good Service Oriented Design.
I'm at a loss for words. I can understand his distaste for the amount of attention that SOA is getting. He actually states that he doesn't like: "IT guru firms that peddle high-priced snake oil as "expert advice" and use high-sounding, yet vague and obscure terminology to cloak the utter banality and limited practical value of what -they're saying." My God Bill - have you looked in the mirror? At least we didn't name it after ourselves!!!
This article, written in the Microsoft Redmond Journal, is the biggest bunch of shit I've seen written since Nicholas Carr put pen to paper.
Bill basically says that SOA has been overhyped, is the same-ole architecture and that it is like CORBA, etc. He goes on to say that the new thing is XML and you can already do that in Microsoft .Net. He also states that, " SOA is a matter of good, modular, object-oriented design..." No Bill, SOA is a matter of good Service Oriented Design.
I'm at a loss for words. I can understand his distaste for the amount of attention that SOA is getting. He actually states that he doesn't like: "IT guru firms that peddle high-priced snake oil as "expert advice" and use high-sounding, yet vague and obscure terminology to cloak the utter banality and limited practical value of what -they're saying." My God Bill - have you looked in the mirror? At least we didn't name it after ourselves!!!
This article, written in the Microsoft Redmond Journal, is the biggest bunch of shit I've seen written since Nicholas Carr put pen to paper.
Thursday, June 07, 2007
Advanced SOA Governance - Negotiation
As we split our monolithic applications into right-sized units of work (services) and pull them back together again with composite applications, we realize that the sharing of assets introduces benefit (subsidized costs, consistent logic, single source of the truth, etc.) but it also introduces new pain, namely change management.
In the last few years, most large enterprises have moved to some variation of the three tiered architecture. Here, the system typically has 4 or 5 layers or tiers:
The stateful interactions that monitor the business processes have been factored out of the business logic, and distributed joins (EII) have become first-order citizens of the architecture.
More advanced Service Oriented Enterprises have adopted this tiering model as the heart of their technical service taxonomy.
This diagram depicts the relationship that services have with the composite applications that consume them. As you can see, some services are required by more than one composite application. This is a core feature of SOA - the sharing of assets across the enterprise to solutions that need them.
Modern SOA Governance practices focus on passing the 'service baton' from one group to the next while verifying that best practices are adhered to and that the baton remains in motion. This movement throughout the software life cycle is managed according to new service/operation requests as well as for change requests. The Service Life Cycle Governance and the Evolution Governance become the primary framework for monitoring change.
The needs (features and functions) of a service will vary by the consuming application. The teams that deal with each software life cycle will need to be aware of the multiple masters (or owners) that they must serve. And on occasion, we can expect that the masters will have disagreements. They will disagree on what it should do, who pays for it, when it should be rolled out, etc. These questions are at the heart of SOA Governance!
As you can see, consuming applications need to approve, prioritize, fund, plan and communicate the changes to shared services. The Service Oriented Enterprise realizes that the services are an enterprise asset, shared for the benefit of the organization. And each business or process owner will, and should, argue for their needs. Ultimately, the group needs to come together to resolve the differences.
SOA will force more occasions where departments and business units will need to find a common ground. I.T. shops have had the need to negotiate for shared infrastructure in the past. If you move forward with SOA, this activity increases significantly. There are no magic answers to SOA Governance. My only recommendation is to make sure that the tools, processes, roles and committees are in place to make the negotiation process as efficient as possible. Said another way, a competitive advantage for the Service Oriented Enterprise is the ability to efficiently negotiate differences and take action.
In the last few years, most large enterprises have moved to some variation of the three tiered architecture. Here, the system typically has 4 or 5 layers or tiers:
The stateful interactions that monitor the business processes have been factored out of the business logic, and distributed joins (EII) have become first-order citizens of the architecture.
More advanced Service Oriented Enterprises have adopted this tiering model as the heart of their technical service taxonomy.
This diagram depicts the relationship that services have with the composite applications that consume them. As you can see, some services are required by more than one composite application. This is a core feature of SOA - the sharing of assets across the enterprise to solutions that need them.
Modern SOA Governance practices focus on passing the 'service baton' from one group to the next while verifying that best practices are adhered to and that the baton remains in motion. This movement throughout the software life cycle is managed according to new service/operation requests as well as for change requests. The Service Life Cycle Governance and the Evolution Governance become the primary framework for monitoring change.
The needs (features and functions) of a service will vary by the consuming application. The teams that deal with each software life cycle will need to be aware of the multiple masters (or owners) that they must serve. And on occasion, we can expect that the masters will have disagreements. They will disagree on what it should do, who pays for it, when it should be rolled out, etc. These questions are at the heart of SOA Governance!
As you can see, consuming applications need to approve, prioritize, fund, plan and communicate the changes to shared services. The Service Oriented Enterprise realizes that the services are an enterprise asset, shared for the benefit of the organization. And each business or process owner will, and should, argue for their needs. Ultimately, the group needs to come together to resolve the differences.
SOA will force more occasions where departments and business units will need to find a common ground. I.T. shops have had the need to negotiate for shared infrastructure in the past. If you move forward with SOA, this activity increases significantly. There are no magic answers to SOA Governance. My only recommendation is to make sure that the tools, processes, roles and committees are in place to make the negotiation process as efficient as possible. Said another way, a competitive advantage for the Service Oriented Enterprise is the ability to efficiently negotiate differences and take action.
Friday, June 01, 2007
SOA is an I.T. Strategy
I've read some stuff lately where people have called SOA a "business strategy". I'll go on a limb and estimate that in 99.99% of the cases where SOA is being used, it isn't a business strategy but rather an I.T. strategy. And you know what? That's ok. There is absolutely nothing wrong with acknowledging that SOA is about making I.T. better. The better I.T. works, the better it can serve the business.
The notion that everything I.T. does is "about the business" is just a little bit silly. Sure, at some secondary or tertiary level it's all about the shareholder. But let's get real... buying rackmount servers is about a more efficient I.T.; standardizing on one or two operating systems is about creating a more efficient I.T - - and sharing common application logic and data across the enterprise is about creating a more efficient I.T.
SOA is first and foremost an I.T. strategy. If you need money from the business to fund SOA, then talk to them using words they understand. But don't kid yourself - this is an I.T. problem and you have to clean up your own mess. If you've created a silo-oriented, sphaghetti integrated, inefficient architecture that slows down your ability to server your internal customers then it's your problem to clean up the mess. Whatever you do, do not insult the business by telling them that you've got a new business strategy called SOA.
The notion that everything I.T. does is "about the business" is just a little bit silly. Sure, at some secondary or tertiary level it's all about the shareholder. But let's get real... buying rackmount servers is about a more efficient I.T.; standardizing on one or two operating systems is about creating a more efficient I.T - - and sharing common application logic and data across the enterprise is about creating a more efficient I.T.
SOA is first and foremost an I.T. strategy. If you need money from the business to fund SOA, then talk to them using words they understand. But don't kid yourself - this is an I.T. problem and you have to clean up your own mess. If you've created a silo-oriented, sphaghetti integrated, inefficient architecture that slows down your ability to server your internal customers then it's your problem to clean up the mess. Whatever you do, do not insult the business by telling them that you've got a new business strategy called SOA.
Subscribe to:
Posts (Atom)