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.