Literally - I was trying to boil some water today. While staring at it, I began thinking, "My God this is taking forever!". A Watched Pot Never Boils. Sadly, too many of my life experiences end up relating to SOA...
Some journalists and bloggers have been critical to the success of SOA. Personally, I view it as a "watched pot". Impatiently staring at an SOA effort and constantly asking, "How many services do we have?" or "What's the ROI?" - doesn't really help.
SOA is a long term change to I.T. - it will take time. I've seen HUGE changes take place in some of the world's largest corporations. I've also seen companies with poor I.T. leadership whine about how they failed. Hell, I could have told them that they would have failed at about anything they tried.
I guess what I'm trying to say is that I don't think that the journalists / bloggers should ask EVERYDAY, "are we there yet?" It's annoying and not helpful. And the LOSERS who threw in the towel - well, they're losers.
Sunday, September 30, 2007
Thursday, September 20, 2007
Budgeting for SOA
Well, it's that time again - I.T. teams around the nation are hunkered down working on their 2008 budgets. All of them are asking the same questions: How much do I need? What will it be spent on? Where can I cut? Unfortunately, I can't answer all of these questions in a blog post, but I can provide some investment categories to consider:
1. SOA Foundation - A good SOA Foundation program is typically a 3-6 month process utilizing internal and external resources. The initiative rolls together a number of common deliverables: SOA Strategy & Roadmap, SOA Methodology Updates, SOA Reference Architecture, Standards Development and SOA Governance Planning. This will typically cost about $200-400k from external resources, and will eat up significant time of 2-4 internal resources.
2. SOA Infrastructure Realization - Over the last several years, software vendors have been perfecting their SOA solutions. Most large organizations evaluate and acquire their software in 4 different stages, often a year apart.
3. SOA Governance Team - After the SOA strategy and roadmap have been defined, the next step is to create an organization that moves SOA forward. Activities include: Program Management, Service Portfolio Management, SOA Infrastructure Architect, SOA Infrastructure Administrator, Service Product Management and typically a couple SOA consultants to engage in active projects and review deliverables. Again, this is typically a combination of internal resources and external SOA consultants. Total combined costs are typically in the $.5 to 1 million range. Also, expect this team to provide significant guidance in the selection of the SOA Infrastructure and to mature the documents defined in the SOA Foundation Program.
4. EA Domain Analysis - All of the expenses on SOA planning, infrastructure and governance is wasted if you don't actually DO SERVICES. It surprises me how many organizations forget this point. Domain analysis is typically performed by enterprise architects who have a strong background in process modeling and service design. They pick a domain area (Sales, Supply Chain, etc.) and perform Process Reengineering, Process Modeling, Service Identification, Service Analysis and Composite Application Requirements Gathering. It is common for these activities to be driven by a Global Process Reeningering effort, or by Application Rationalization / Consolidation efforts. These efforts vary significantly in size, but rarely can you analyze an enterprise domain for under $300k. It is typical for an organization to be analyzing multiple domains in parallel. Most EA teams I've met with are already fully utilized, have minimal budget and don't have time to perform this work. Plan on either adding permanent members to the team or bringing in on-demand external resources.
5. SOA Training and Change Management - Unfortunately, we're not born with SOA skills, we must be trained. Managers, analysts, architects, developers, QA professionals and operational support personnel must all be trained in their piece of the solution. Even after training, you'll find that some people didn't make the change (Silo Oriented Architects), and you will need to provide some degree of change management to either get them on the right page or get them out of the way. Most organizations that we're dealing with are sending 100-300 people to training and are sending IT leaders to conferences. I'd plan on $150k to 400k for getting the teams up to speed.
5. SOA Build and Integration Teams - As organizations continue business as usual, they are constantly bringing in new packaged applications as well as building new systems for their business customers. Going forward, these systems will be sent through the SOA Governance Center. In some cases, the Governance team will determine that they shouldn't be services and will pass them through. In other cases, the systems will be required to adhere to the Governance standards. Packaged applications will often require 'service enablement' and 'service oriented integrations'. New systems will require 'SO-analysis, design, construction and testing'. If you think that your offshore teams will be building your first services, well, you're probably wrong. Service design and construction, like anything new, will most likely be done by in-house teams or on-shore development centers. After the art of SOA Build and Integration is turned into more of a repeatable discipline, you should strongly consider moving this to your favorite commodity development center. For planning purposes, I recommend that you first get a non-service orieneted cost using your internal estimating scheme. Then add on an extra 20-35% to turn the the software into hardened, reusable shared services.
I've said it before and I'll say it again... SOA Transformations cost big bucks, take years to complete but in the end are worth the investment. I hope that this off-the-cuff analysis is valuable to you. Again, it is impossible for me to provide anyone with accurate advice without knowing their situation. I'm currently running around the country helping large organizations put together their precise 2008 SOA budgets. If you need an extra hand looking at your situation - feel free to reach out to me: e-mail me
1. SOA Foundation - A good SOA Foundation program is typically a 3-6 month process utilizing internal and external resources. The initiative rolls together a number of common deliverables: SOA Strategy & Roadmap, SOA Methodology Updates, SOA Reference Architecture, Standards Development and SOA Governance Planning. This will typically cost about $200-400k from external resources, and will eat up significant time of 2-4 internal resources.
2. SOA Infrastructure Realization - Over the last several years, software vendors have been perfecting their SOA solutions. Most large organizations evaluate and acquire their software in 4 different stages, often a year apart.
Stage 1 software is typically a combination of Registry, Repository, Mediation and Web Service Management. For an enterprise license this is typically $750k - 1.25, depending on the size of the organization.
Stage 2 is typically a combination of security and integration. This often includes SOA firewalls and other edge devices. For integration, most organizations are looking at ESB's, orchestration engines and service engines / adapters. Plan on $400-800k for Stage 2.
Stage 3 is typically a combination of EA and Advanced Integration. Organizations that don't have EA modeling tools are quickly bringing them in house and are laying the foundation for their process, service and information modeling needs. Advanced Integration is usually a combination of Data as a Service tools (EII, MDM) as well as legacy host integration. Stage 3 can be quite expensive depending on what all you need. If you're starting from scratch, plan on $1 to 2.5 million for all of it.
Stage 4 is primarily focused on using the services. This includes client side platforms (AJAX, Web 2.0, Next-Gen Portal, Composite Application Tools, etc.) as well as the quality tools to verify the services. From a quality perspective, organizations are buying SOA testing platforms as well as asset governance tools. Comparatively, this area is a bit cheaper, plan on $250 to 800k.
3. SOA Governance Team - After the SOA strategy and roadmap have been defined, the next step is to create an organization that moves SOA forward. Activities include: Program Management, Service Portfolio Management, SOA Infrastructure Architect, SOA Infrastructure Administrator, Service Product Management and typically a couple SOA consultants to engage in active projects and review deliverables. Again, this is typically a combination of internal resources and external SOA consultants. Total combined costs are typically in the $.5 to 1 million range. Also, expect this team to provide significant guidance in the selection of the SOA Infrastructure and to mature the documents defined in the SOA Foundation Program.
4. EA Domain Analysis - All of the expenses on SOA planning, infrastructure and governance is wasted if you don't actually DO SERVICES. It surprises me how many organizations forget this point. Domain analysis is typically performed by enterprise architects who have a strong background in process modeling and service design. They pick a domain area (Sales, Supply Chain, etc.) and perform Process Reengineering, Process Modeling, Service Identification, Service Analysis and Composite Application Requirements Gathering. It is common for these activities to be driven by a Global Process Reeningering effort, or by Application Rationalization / Consolidation efforts. These efforts vary significantly in size, but rarely can you analyze an enterprise domain for under $300k. It is typical for an organization to be analyzing multiple domains in parallel. Most EA teams I've met with are already fully utilized, have minimal budget and don't have time to perform this work. Plan on either adding permanent members to the team or bringing in on-demand external resources.
5. SOA Training and Change Management - Unfortunately, we're not born with SOA skills, we must be trained. Managers, analysts, architects, developers, QA professionals and operational support personnel must all be trained in their piece of the solution. Even after training, you'll find that some people didn't make the change (Silo Oriented Architects), and you will need to provide some degree of change management to either get them on the right page or get them out of the way. Most organizations that we're dealing with are sending 100-300 people to training and are sending IT leaders to conferences. I'd plan on $150k to 400k for getting the teams up to speed.
5. SOA Build and Integration Teams - As organizations continue business as usual, they are constantly bringing in new packaged applications as well as building new systems for their business customers. Going forward, these systems will be sent through the SOA Governance Center. In some cases, the Governance team will determine that they shouldn't be services and will pass them through. In other cases, the systems will be required to adhere to the Governance standards. Packaged applications will often require 'service enablement' and 'service oriented integrations'. New systems will require 'SO-analysis, design, construction and testing'. If you think that your offshore teams will be building your first services, well, you're probably wrong. Service design and construction, like anything new, will most likely be done by in-house teams or on-shore development centers. After the art of SOA Build and Integration is turned into more of a repeatable discipline, you should strongly consider moving this to your favorite commodity development center. For planning purposes, I recommend that you first get a non-service orieneted cost using your internal estimating scheme. Then add on an extra 20-35% to turn the the software into hardened, reusable shared services.
I've said it before and I'll say it again... SOA Transformations cost big bucks, take years to complete but in the end are worth the investment. I hope that this off-the-cuff analysis is valuable to you. Again, it is impossible for me to provide anyone with accurate advice without knowing their situation. I'm currently running around the country helping large organizations put together their precise 2008 SOA budgets. If you need an extra hand looking at your situation - feel free to reach out to me: e-mail me
Wednesday, September 19, 2007
Terry White on SOA
I just caught a great comment that Terry White, EDS Fellow, left:
I couldn't agree more. This is very similar the process that we do at MomentumSI. I'm glad to hear that others are having success as well.
A good approach is to develop a taxonomy that is easily understood by all involved. We recently developed an Enterprise Architecture that was SOA based. It didn’t really look that much different from any other Enterprise Architecture that is modular and effectively layered.
In developing this architecture we involved people from both the IT and business areas of the company. When we first started the context was purely business process – re-engineering and decomposition. We moved them to a services view for looking at the business processes. Then we added the IT “application” details and show how business services would be supported by application services. We decomposed the existing application landscape and re-ordered it to align with the business services.
Business processes have owners, or people responsible to manage them as assets. Applications have owners. Now the move is for services, both business and IT application, to have owners and be managed more like products. One potential problem I noticed is that management tends to count the number of applications supporting their business and work to reduce that number. When we move to services and managing services, there is an automatic increase in things you are managing because before these were all just application functions buried within the application. Aggregating the services can help but it is a bit of a mind shift.
I couldn't agree more. This is very similar the process that we do at MomentumSI. I'm glad to hear that others are having success as well.
Thursday, September 13, 2007
Using SOA to Align I.T. with Itself
After much consideration, I've come to the conclusion that SOA is best suited to facilitate "I.T. and I.T. Alignment" (not Business and I.T. Alignment). That is to say, SOA (from an enterprise architecture perspective) is better suited to align internal I.T. efforts with other internal I.T. efforts. This might sound like common sense (and hopefully it is), but SOA is fundamentally about sharing common logic and data while facilitating accurate and complete client side consumptions.
I had a conversation with a gentleman the other day. I'll paraphrase his comments... he asked me to imagine an enterprise without computers or software systems. Instead, it had one Filing Room that people went to when they needed to store or retrieve data.
At the front of the Filing Room were people working the Service Counter to fulfill your requests. In the back of the room were Filing Clerks who kept the filing system organized.
In this model it was assumed that the people in the Filing Room did a good job of organizing their files, as to ensure that when a customer asked for "all customers", they didn't have to go to 5 different Filing Cabinets. It was the responsibility of the Filing Clerk to facilitate Master File Management. The Chief Filing Officer was responsible for making sure that the Filing Cabinets stayed organized and on occasion were reorganized.
The "Service" in SOA is the new filing cabinet. Our SOA Governance Teams will work the front counter taking requests and also verify that they filing clerks do their job correctly. They must ensure that the portfolio of filing cabinets stay organized and avoid duplicate filing systems. And ultimately, the CIO must be held responsible for the state of the Filing Room.
SOA is not a holistic EA framework, but it will provide the taxonomy and organizational structure to become the foundation for a single enterprise system of services.
I had a conversation with a gentleman the other day. I'll paraphrase his comments... he asked me to imagine an enterprise without computers or software systems. Instead, it had one Filing Room that people went to when they needed to store or retrieve data.
At the front of the Filing Room were people working the Service Counter to fulfill your requests. In the back of the room were Filing Clerks who kept the filing system organized.
In this model it was assumed that the people in the Filing Room did a good job of organizing their files, as to ensure that when a customer asked for "all customers", they didn't have to go to 5 different Filing Cabinets. It was the responsibility of the Filing Clerk to facilitate Master File Management. The Chief Filing Officer was responsible for making sure that the Filing Cabinets stayed organized and on occasion were reorganized.
The "Service" in SOA is the new filing cabinet. Our SOA Governance Teams will work the front counter taking requests and also verify that they filing clerks do their job correctly. They must ensure that the portfolio of filing cabinets stay organized and avoid duplicate filing systems. And ultimately, the CIO must be held responsible for the state of the Filing Room.
SOA is not a holistic EA framework, but it will provide the taxonomy and organizational structure to become the foundation for a single enterprise system of services.
Subscribe to:
Posts (Atom)