A Watched Pot Never Boils - SOA Style

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.

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.

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

Terry White on SOA

I just caught a great comment that Terry White, EDS Fellow, left:

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.

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.

SOA Consolidation - Updates

I finally updated the SOA consolidation list:
http://www.momentumsi.com/SOA_Acquisitions.html

The clock is ticking on some of the smaller firms...

Software M&A Rumors

I noticed two items of importance this week:
1. The Dow hits an all time high
2. Rumors of VERY LARGE M&A activity in the I.T. space are off the chart

I'll avoid perpetuating any of the rumors that are going around; talk is cheap. What seems evident is that both I.T. buyers and providers seem bullish on the idea of massive consolidation. Our industry has been in constant flux for a long time, exhibiting all the signs of an immature industry.

Despite our strong economy, many of the preeminent brands continue to bleed money while failing to create a differentiated product portfolio. The buying community has rewarded platform commoditization and 'design to standardization'. Cloners and imitators have shown their ability to rapidly re-create innovator's products using open source and competitive pricing models.

Most large ISV's have already executed on a significant number of acquisitions and have had to become experts in integrating their own products. As their ability to refactor, integrate and generally absorb new products grows, so does their desire to capture additional market share through acquisition.

The unanswered question is where is this all leading? I'm confident that we'll see a few models emerge. However, the one that seems obvious is the one-stop shop. One company provides hardware, software infrastructure, packaged applications and professional services. With the growing popularity of SaaS, we can anticipate that multi-tenant hosted application support will also be a key element. The other trend that can not be discounted is the use of offshore resources to provide low cost labor.

I believe that massive consolidation is both inevitable and necessary. Information and technology providers must reach the next level maturity. They must be able to provide end-to-end solutions and take full responsibility.

Service Lead Management

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"!

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.

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.

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.

Did the SOA Community Fail You?

Yesterday, I had an interesting discussion with another SOA veteran on the subject of barriers to successful SOA. The conversation led to a fairly obvious conclusion that several parties aren't pulling their weight. The parties we discussed included: the Venture Capital Community, Standards Bodies, I.T. Analysts, the Press, the Academics, SOA Infrastructure Vendors, Consulting and Training Vendors, Packaged Application Vendors and Design Tooling Vendors. Here is my personal view on their success:



Venture Capital Community
The VC's did their job. They invested early; many of the investments were made in the days following 9-11 which was a tough time for anyone to invest, but they did it. And when they did, they funded deep - but not too deep. It wasn't crazy dot-com investment. As their investments grew up, they did a good job helping them to find parent companies. On a scale of 1 - 10 stars, I'll give the VC a solid 10 on SOA.

Standards Bodies
Many will argue that a key enabler of SOA was the creation of Web Service standards. The creation of SOAP, WSDL, UDDI and the WS-* stack has been both a blessing and a curse. Often the concepts of SOA are tied to implementations and the limitations of those implementations are then attached to SOA. This is a tough one for me to score. IMHO, the real standards work was done behind closed doors at IBM and Microsoft and then handed to the standard bodies for cleaning and revising. In some cases the standards bodies did more harm then good. Overall, I'll give them 6 stars.

I.T. Analysts
The I.T. analysts got on the SOA bandwagon pretty early. Overall they did a good job of covering an extremely broad subject. Boutiques like ZapThink, Burton Group, CBDI and Macehiter Ward-Dutton showed precision analysis and deep insight. While Gartner, Forrester and IDC all did a sincere job covering the space, their insights often lagged the blogs and mainstream media. I'm giving the I.T. Analysts 8 stars.

The Press
The press has been overly generous on the topic of SOA. Most of the large publications have a regular column on SOA and even an SOA blog. Some, like Infoworld, have even held SOA conferences. I think that the reporting has been fair, but often light. Maybe I'm too old, but I remember back when magazines would do more lab testing and comparing products. This just doesn't seem to happen very often anymore. Now, we vote on 'hot products'; how lame is that? If the press would bring back the labs (or more case studies), I'd give them a solid 10. But lacking this I have to give them a 7.

The Academics
I have no expectations for the academics to do anything. And in my opinion they haven't. They're just where I like them. Hence, they get a solid 10.

SOA Infrastructure Vendors
Infrastructure such as: XML Appliances, ESB's, Orchestration Engines, Smart Intermediaries, Web Service Management/Monitoring, Registries and Repositories became mainstream in the SOA era. For the most part, I was impressed with the ingenuity that the startup's demonstrated in forging their products. And even some of the big guys like IBM showed that they have game. I'd love to give these guys a solid 10 but I can't. It's because of the big lie. These vendors have told customers that their products work with each other and for the most part they don't. HP/Systinet promoted the Governance Interoperability Framework as a solution, but in my personal opinion, they completely failed to deliver. And the rest of the vendors have sat on their lazy asses acting like the problem doesn't exist. I'm giving them 7 stars. How ironic is it that SOA vendors lose 3 stars for having a lack of interoperability?

Consulting and Training Vendors
As a consulting and training vendor - this is a hard one to do. There are a few companies like MomentumSI that I believe are doing a good job of helping organizations make the transition to SOA. The problem is that there are only a few doing a good job and a very large percentage who are not. Consulting companies should be able to quickly deliver SOA best practices, methodology adjustments, job descriptions, project mentoring and deep knowledge on tough subjects like governance and change management. For the most part, the big guys (Accenture, BearingPoint, CSC, EDS, SAIC, WiPro, etc.) are still very immature. There are a few notable exceptions, in my opinion Infosys, CGEY and IBM Global Services are all making sincere attempts to build out their SOA competency, with IBM leading the pack. I'm going to have to give this category 6 stars.

Packaged Application Vendors
First, as long as this category is called 'packaged apps' and not 'packaged services' I'm probably going to bash it. I remember back when we used to talk about the end of 'big bang implementations'. This was the idea that you wouldn't spend 3 years installing and configuring a huge monolithic application like SAP. Instead, you'd do it one service at a time. Ha! The packaged app companies were quick to get on the SOA bandwagon. They realized that this paradigm offered a genuine threat to their model and were quick to say that they embraced it. The question is, "embraced what?" That they'd web service enable BAPI's and hide the ABAP code? You've gotta be joking? And there is a reason why people refer to the Oracle strategy as conFUSION. Without a doubt, the best thing that these guys have done is made promises about SOA indicating to customers that SOA is the future. Yes, because of their marketing efforts I am forced to give this category 2 stars.

Design Tooling Vendors
In every paradigm change, we require new tools to facilitate the new architecture. In past generations we saw wonderful products like Rational Rose, ER/Win and TogetherJ rise to the occasion. I am so disappointed in the lack of progress in this category. The EA modeling vendors have demonstrated 'pompous ignorance' and failed to deliver anything resembling modern SOA tooling. Notational standards for service models remain in their infancy. I firmly believe that the lack of SOA modeling standards and tools will defer the adoption cycle. This category deserves zero stars.

---

Now the burden is on the buyer. Did the SOA Community fail you or will you fail it? It is the responsibility of every buyer to push the community to do a better job. Money talks.

Talking to the Business about SOA

I often recieve the question, "How do you go about talking to the business about SOA?"

Here's my advice. Don’t lump all non-I.T. functions into a single bucket called the business! We must know our audience and create a message that they can relate to.

FINANCE
There are many definitions of SOA, but my favorite is to describe SOA as an 'I.T. economic model focused on cost savings through increased utilization of existing enterprise assets'. First and foremost, shared services should be viewed as a subsidized and highly leveraged asset that lends itself to supply and demand economics.

From a slightly different perspective, we can say, “SOA is an I.T. investment model that allows you to view your enterprise I.T. assets from a portfolio perspective enabling precision investing.” Here, the focus is on the granularity of the investment. By breaking large, monolithic investments into smaller units we have increased our ability to specify and evaluate individual investments.


PROCUREMENT
In the past, it was difficult for I.T. to divide up large systems into smaller units and have each smaller unit sourced individually. In order to do this successfully, you need to be able to specify how they will reintegrate by using common standards. Recently, I.T. has made a significant advance in these standards and we are now able to employ a multi-sourcing strategy for very large systems. In fact, buying large pre-integrated systems that are proprietary is now considered a worst practice.


LEGAL
I.T. has finally learned that we need to specific software requirements using precise terminology. We’re now using “digital contracts” to specify the functionality of the systems that we will build or buy. SOA makes I.T. focus on knocking out the contract before we start doing the work. This will allow us to hold internal and external parties accountable for their work products. We’ve also adopted a model for incorporating Service Level Agreements so that on-going satisfaction can be reviewed.


CORPORATE DEVELOPMENT & GROWTH
Corporate development groups must evaluate the risk and costs of performing acquisitions. Integrating the I.T. systems of acquired companies is generally considered a high risk and a costly endeavor. SOA enables the newly acquired systems to be leveraged in a shorter time frame facilitating business and system integration. In essence, SOA is the I.T. strategy for enabling mergers and acquisitions.

The assumption here is that the I.T. department is identifying ‘master services’ and ‘master data’. Newly acquired I.T. systems are rolled underneath these services.


PROCESS IMPROVEMENT
Most mature SOA programs have adopted a ‘process driven’ approach to business and service analysis. By analyzing business capabilities, processes and activities, SOA services and operations can be discovered. This enables I.T. to promote (and often fund) the use of formal process analysis. In addition, since services have been broken into smaller units of work, we now have greater visibility into each unit. This is a key enabler of business process management and monitoring. Now, process improvement specialists can utilize a ‘process driven, service oriented’ approach to monitoring the business and recommending improvements.


THE P&L OWNERS
At the end of the day, someone owns the P&L. This could be the CEO or a business unit head. Organizational leaders need to hear:
- You have a new I.T. strategy that benefits the entire company.
- The strategy can be successful through incremental investments but it will require an initial out-of-the-gate investment.
- If successful, you’ll be able to significantly reduce I.T. costs without sacrificing results.
- The entire I.T. and software industry is heading down this path, so eventually we’re going to be impacted by this software model. The only question is do we want to invest now to get ahead of the curve.

Unlike previous I.T. paradigms, SOA is not about changing out your hardware or creating a new ubiquitous user interface. For the most part, SOA is invisible to the users. This paradigm is harder to explain than others but if done correctly, it's easier to justify.

Try to avoid lumping all non-I.T. personnel into a unit called, “the business”; it’s not ‘us and them’. Know your audience and what they understand and value. SOA is a complex model that has many advantages. The key is to know which advantage to pull out and when!

Composite Service Analysis

A common scenario that I see is the case where an organization wants to build a new application with the intent of 'finding services' in the implementation of the project. This is common because current I.T. governance favors 'project funding'. This begs the question, what does the process look like for capturing requirements for a silo-oriented application in a service oriented, mashup, process driven world?

First and foremost, we must recognize that we are not in the object oriented world where we captured requirements as if there were only one type of logic. We live in a world of domain specific languages and self describing interfaces. Capturing requirements as if we didn't know that kind of input our downstream partners need is just plain silly (and obsolete).
A simplified view of the new process looks like this:


Today, we leverage our downstream partners (UI, design, architecture) to help drive full and useful requirements. The analyst leverages the UI/Mashup/Composite specialist to create mockups, prototypes and even working user interfaces. The UI's are then presented back to the business users to help validate the requirements. UI's typically are good at conveying a single users role in a larger process but fail to paint the big picture. To bring breadth to the table, the analyst will call on a process and integration specialists to clarify process steps, human workflow and even the flow of information between legacy systems. In most cases, the 'composite services', 'integrations' or 'process logic' calls atomic services. This is where fine grained business rules, calculations and constraints are housed. The anlayst will leverage the skills of a Service Designer to stub out or mock up an interface (WSDL) along with a dummy implementation.

Our goal is to use a combination of rapid prototyping and extreme programming to quickly create releases that can be presented to the business community for feedback. Modern analysis embraces the following key concepts:
1. It acknowledges that some functions will be shared (as services)
2. It embraces various types of logic (presentation, process, data, etc.) and documents those requirements in a manner that makes sense to the people who have to build it
3. It leverages the techniques we've learned in spiral, iterative, RAD and agile methods limit risk and involve the user

Remember - SOA is only a piece of the puzzle.

Service Domain Analysis

Today, most organizations have someone who owns an application. The ownership is often split between two areas. One group will own the budget and control of features while the other group owns engineering and staffing decisions. In the service oriented world this will likely stay the same. One potential difference is the scope of ownership. With the popularity of mashups and composite applications new customer facing systems are being designed around the needs of the user rather than around a specific domain. Many of these systems are 'process oriented' and cross several business domains. This makes it hard to determine who owns it.

In a service oriented enterprise, you have a 'owners' of services and 'owners' of composite applications. The service owners are domain focused (manufacturing, sales, etc.) while the composite application owners will be process (or problem) focused. Service owners focus on creating consistent logic and having 'a single version of the truth'. Composite app/mashup owners work with the end users to understand their day-to-day computing needs. Their job is to deliver the right information at the right time to their users. They leverage the service teams to provide the right information.

Today, many organizations have not split their groups into 'service teams' and 'client teams'. This typically requires a re-org and as I've mentioned before is a SLOW process. In the meantime, I'm suggesting the following process:



In this scenario we have a project analyst who is working with a business user to determine their needs. They will employ a variety of techniques to uncover the requirements. The analyst will often be trained in rapid prototyping (Web 2.0 style) or work with others with that skill set. They will also use Service Oriented Analysis techniques to identify potential services and scope them out. The analyst will document their findings in a form different than legacy silo systems. They will use a combination of Service Cases and Operation Cases. These cases are used to fully describe that portion of the system which would be shared and controlled as a service. The portfolio analyst works with the project analyst to verify that the candidates are valid (reusable, distinct, etc.) and create a placeholder for the service, know as a Slot or a Service Slot.

There are a variety of techniques for performing Service Oriented Analysis. At MomentumSI, we utilize a set of practices known as Harmony™. In the coming months, we'll be discussing these practices in detail.

Starter SOA, Part 3

So far we've discussed a few concepts that organizations can take on without too much pain:
1. Get the project disciplines to talk with the enterprise guys about SOA
2. Create a SOA Steering Committee to start a dialogue between enterprise disciplines

Number 3 is a bit harder for some organizations. It deals with money, or the lack thereof. The heart of the problem is that the funding process in most I.T. organizations still doesn't facilitate the SOA paradigm. In the past, systems were generally funded as a standalone 'application' that had one owner. Going forward, funding will be broken into:
- Shared Services
- Composite Apps / Clients
- Non-Shared Services (services with one consumer/client; temporarily dedicated)
- Shared infrastructure (reg/rep/esb/wsm/etc.)
- Non-Shared Infrastructure (service container, app server, etc.)

Within each of the aforementioned areas, the dollars will be broken down by the various support groups (engineering, operations, etc.)

The SOA Steering Committee must be capable of recommending financial models that support the future paradigm. Most organizations already have some mechanism to make a request for shared investments. The SOA initiatives must work together to create a standard model for joint investment as it deals with services. Initially, the request looks like an exception to the rule but after time shared investment will become the norm and non-shared investments will be critically reviewed.

Starter SOA, Part 2

Many organizations seem to hit the brick wall on SOA when one of four things happen:
1. Their isn't a critical mass of SOA enthusiasts
2. No one will pay for SOA infrastructure
3. No model for funding or governing shared services exists
4. Doing SOA right requires a reorganization of I.T.

Simple SOA is primarily directed at the 4th problem. Most I.T organizations have groups that "own applications" or dare I say, they "own monolithic, tightly coupled applications" - they don't own "shared services" (business or technical). Doing SOA right usually requires a new I.T. reporting structure but this can be a SLOW process.

So, the second concept I'm promoting is the use of an SOA Steering Committee.


As I mentioned in my last post, an early (and easy) step to take is having project teams leveraging the enterprise disciplines. Application architects should be working with their counterparts in EA, etc. Once the project teams begin communicating with the enterprise disciplines, the natural progression is to get all of the enterprise disciplines talking to each other.

The agenda for a typical SOA Steering Committee is:
10 minutes - The status of the SOA Roadmap: what is done and what isn't
20 minutes - A review of any new artifacts or SOA deliverables
20 minutes - A discussion on problems that the project teams are encountering
10 minutes - Recommended changes to the SOA Roadmap

It's a simple meeting that is cross-discipline. The team uses a program plan (SOA Roadmap) to keep a list of initiatives visible. The roadmap remains 'agile' and reacts to findings in the field. A fundamental goal of the team is to address issues that pop up quickly and to take decisions back to their respective teams.

In the beginning the team will likely meet often (every 2-4 weeks) and as the program matures the team will probably meet quarterly or until stabilization is realized.

Starter SOA

Many large organizations are trying to figure out their new processes around SOA. I've been involved in a handful of these efforts. Typically this will involve a cross-discipline team who reviews current processes (RUP, ITIL, COBIT, etc.) to determine what must change in a service oriented world. Although I fully support this model, I've also noticed that this is a LONG and difficult road. This got me thinking... how do you do "starter SOA"?

Of course, I'm less interested in the technology/architecture side of SOA and I'm more interested in the people/process side. We have literally hundreds of modified SDLC processes that depict changes to support SOA. It's great stuff. But I've determined that it is too much to convey the basic idea of what we need to get done. This led me to create a simple picture about what I believe is at the heart of the SOA issue.

The basic idea that I'm suggesting is this:

1. Don't roll out all of the updated disciplines at once - pick a few key disciplines and insert them into the process.

2. Attack three specific areas: Portfolio Mgmt, Enterprise Architecture and Information Management.

Again, this won't solve all of your SOA problems but it will solve many of the problems related to 'Master Service Management' and basic SOA Governance. As this simple process becomes part of the regular work stream you can begin bringing in more and more disciplines like Operations, BPM specialists, Shared Service Groups, etc. My primary warning is don't wait until you have ALL your ducks in a row to get started - it may never happen.

ERS - Empty Registry Syndrome

I've met a number of organizations recently that seem to have a bad case of ERS, or Empty Registry Syndrome. This disease must be taken seriously. It is known to be fatal to service oriented initiatives.

Common causes of ERS include:
- Not having a 'shared services group'
- Not monitoring the project pipeline and identifying service early
- Silo-Oriented requirements gathering
- Buying a bad registry

Luckily, ERS is completely curable. By changing habits an organization can usually treat the disease in 3-9 months. It should be noted that the treatment can be painful and takes real commitment.

Common treatments:
- Give the development organizations goals related to service creation. The SOA initiatives MUST move beyond enterprise architecture and integration centers
- Revise the I.T. governance, funding and portfolio management processes to find services early
- Train business analysts and application designers to 'identify, analyze and design' services; people were not born with this skill
- Verify that your registry doesn't stink. Here's the test: If you search for a service that doesn't exist does it return with:
A) No results found
or
B) No results found, would you like to request a new service?

If the answer is "A" please call your vendor and let them know that their software is spreading a disease known as ERS.

Hattrick Software & Choreography

Steve Ross-Talbert has his fingers in a couple start-ups:
Hattrick Software focuses on Web Service Choreography:
http://www.hattricksoftware.com/

He blogs about some of his reasoning here: http://pi4tech.blogspot.com/

The original WS-CDL specification was less than impressive, however, the concepts were right on. I haven't gone back to revisit the specs but I will. It will take people some time to understand the fundamental 'centralization' problem associated with BPEL. Until then, alternatives will largely be ignored.

Lustratus Research on SOA

I just ran across this site which provieds SOA insight:
http://www.lustratusresearch.com/store/default.aspx