June 27, 2009
There are many organizations – large and small – undertaking SOA initiatives. As much as the technical infrastructure, message processing, service governance, and web service monitoring are important for your SOA you cannot afford to ignore the organizational aspects. In this post, I want to not focus on your entire enterprise but your department or a group of development teams undertaking SOA initiatives. When aspiring for SOA success you have to have more than developers and technical leads on your side.
So who else needs to be involved? You need your requirements analysts, your data modelers, and production support staff all singing the SOA tune albeit in their unique voices. This post will talk about requirements analysts.
Many developers underestimate the impact of requirements analysts (also referred to as system analysts or business analysts). Some analysts mix requirements with design offering specific solutions to business needs. Requirement specifications end up becoming design documents. Why is this a limiting factor for SOA? Because, you want to identity candidate services, reuse existing service capabilities, refactor legacy and modern assets and govern these service capabilities as part of your SOA strategy. Imagine, sifting through a requirements document that specifies implementing functionality as stored procedures or batch jobs. Without care, this can influence your thinking – knowingly or unknowingly binding you into solutions that are not in line with your SOA goals.
You want your requirements analysts to specify the business processes the application needs to automate, enhance and the business capabilities required. You can then deduce the business services, the enterprise data services, and the BPM workflows that need to be developed. If your analysts are receptive you should persuade them to use a modeling tool that can specify an analysis model using a vendor neutral notation that can be imported into a BPM engine and converted into an execution flow. All said and done, the deeper point isn’t BPM or analysis model but about the what of the system. Using the what you can design the how. That is where SOA comes in addressing questions around what services you will build, which ones you can integrate with, which ones to decommision, and which ones to change. Requirements should clarify and not prematurely solve technical problems.
Ask your analysts to provide world class requirements including functional and non-functional ones. Persude them to stay away from providing technical solutions so you can figure out how to automate your firm’s processes within the context of your SOA efforts. This isn’t easy and won’t be possible with every project but that shouldn’t prevent you from trying!
Like this post? Subscribe to RSS feed or get blog updates via email.
: 
: 
: 
: 
:
2 Comments | 
Planning, Reuse, SOA | Tagged: BPM, business process, Business process management, requirements analysis, Service-oriented architecture, software reuse, Workflow | 
Permalink
Posted by vijaynarayanan
June 26, 2009
I often talk to folks who believe that SOA is about creating services. While that is partially true it isn’t the complete picture. The goal of SOA is not service creation but business transformation. Creating a service is a necessary but not sufficient condition for SOA success. You create services to orchestrate legacy capabilities, execute business rules, and manipulate enterprise data.
But, all these are done within the context of business objectives (at least you need to aspire to do that!)
Succeeding with SOA involves utilizing services – multiple kinds of services – to implement functionality, automate business processes, and achieve business objectives. As a by product if you follow reuse-friendly techniques and practices you will build up a service inventory that can be leveraged for future projects. But building up a service inventory isn’t the primary objective – it is a by product of executing SOA right. It means designing, implementing, productionizing, and governing services that are of value to your business, to your domain.
Like this post? Subscribe to RSS feed or get blog updates via email.
: : : : :
Leave a Comment » | Design, General, Reuse, SOA | Tagged: domain ineventory, reusable services, SOA, software reuse | Permalink
Posted by vijaynarayanan
June 14, 2009
Service Mediation is an abstraction layer in between the service consumer and the service provider. What is the need for mediation and what benefits does it provide? There are several benefits:
- Apply cross cutting concerns such as authentication, encryption, logging, metrics across all service requests. The mediation layer can have hooks in place to perform these concerns so individual service capabilities don’t have to invoke them each time.
- Provides the service provider the flexibility to change implementations or service fulfillment strategy. For example, you can migrate a service capability from one programming language to another or get off a legacy system. You can also switch technologies fundamentally – instead of looking up data from a database to fulfill a service request you can read from an in-memory cache or introduce an indexed search engine.
- Mediation can also be used to translate physical transports to fulfill a service request. For example, you might have a capability that is available over HTTP and the consumer might need the capability to be accessed via a Java Messaging Service (JMS) queue. The mediation layer can intercept the request via a JMS input queue and turn around and invoke the underlying HTTP service.
- Services may not always expose the right input/output contracts. There might be legacy syntax/semantics exposed, or inconsistent error codes or too many parameters being exposed etc. More importantly service contracts need to align with your firm’s logical data models. This provides consistent business names, data structures, and decoupling from physical data.
This is just a starter list and there are many additional benefits when adding a mediation layer. I didn’t touch upon governance specifically but they are present in the points above.
Like this post? Subscribe to RSS feed or get blog updates via email.
: : : : :
4 Comments | Design, Reuse, SOA | Tagged: decoupling, logical data model, service mediation, SOA, software reuse | Permalink
Posted by vijaynarayanan
June 9, 2009
Business events – whether they are initiated by human users or system processes – either initiate, change the state of, communicate out of , or terminate business processes. A standard event processing can be used to capture events, enrich them, analyze them, and handle them via appropriate event handlers. This infrastructure could be used to log, track metrics, and most importantly determine the appropriate orchestrations to execute for successful event processing.
As this processing matures you can introduce business rules and business intelligence based event analysis, routing, and enrichment. Iteratively you can also build out a library of business events and associated event handlers that can be reused across multiple projects and initiatives. On a related note you will want your legacy systems to send and consume events in the same format as your strategic platforms. This will facilitate a seamless transition when you migrate functionality off legacy systems by reducing the need to redo event generation, processing, and decision logic.
: : : : :
3 Comments | Design, Reuse | Tagged: events, SOA, software reuse | Permalink
Posted by vijaynarayanan
Just posted the seventh episode of the ![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=e5502cfd-75e0-4dfd-bd37-98ed1b112cf8)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=73f6cbf3-3a96-4b51-9987-d40b15027144)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=7511f00c-9f0c-4fc4-b145-4db48b0e7afc)
