Getting Organized for SOA Success

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.wrongtarget

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.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


SOA Success Is More Than Service Creation

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.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


Software Reuse Tips Article

June 23, 2009

Article on software reuse tips recently got published at infoq.com…

infoq Here is the link:

http://www.infoq.com/articles/vijay-narayanan-software-reuse

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


SOA and Reuse – New Podcast Episode

June 21, 2009

Want to listen using iTunes?

Using iTunes?

podcastJust posted the seventh episode of the software reuse podcast series covering how reusable services and Service Oriented Architecture (SOA) go hand in hand to generate new revenue and save costs.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

Reblog this post [with Zemanta]

Building Reusable Services Meetup Talk

June 19, 2009

I recently presented at the Silicon Alley NYC Meetup on service orientation and building reusable services for Service Oriented Architecture (SOA) initiatives.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

Reblog this post [with Zemanta]

Software Reuse Quick Tip #13

June 18, 2009

Tip # 13 Reuse Data Schemas in Business Process Orchestrations

When implementing business process orchestrations, look to reuse data schemas. This has several benefits:

  • Reusing data schemes will make your business process interfaces simpler and more modular. You will be able to decouple processing data from core entity data.
  • Data transformations from business process orchestrations to data services will be minimal (if any) because the interfaces will use identical data structures. This is often referred to also as using a canonical data model.
  • This reduces maintenance effort on the schemas themselves because multiple business process will leverage these data schemas.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

Reblog this post [with Zemanta]

The Value of Service Mediation

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:Service Mediation

  1. 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.
  2. 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.
  3. 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.
  4. 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.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


Pursue SOA with reuse in mind

June 11, 2009

Many organizations are pursuing SOA initiatives to achieve business process transparency and agility. While executing on projects you don’t want to lose sight of a reusable inventory of services that you can build for meeting your current and future needs. As much as immediate deliverables are important you should always look for reuse opportunities in the following areas:

  1. Integrating user interface tier with the business tier – look to create reusable business services to initiate business processes and get status of business processes. If a business process needs to be customized encapsulate these variations using business rules and configuration. Aspire to define a “template” process which hooks for plugging in product-specific or line of business-specific variations in functionality. Also define a standard set of business actions that any user interface can leverage. This is effectively to decouple the user interface from the business layer so additional apps can leverage your processes
  2. Integrating with legacy systems – this should be your #1 area for reuse. Never let go of an opportunity to wrap a legacy capability as a business or data service. Ensure your service capabilities are categorized appropriately and service interfaces are devoid of legacy semantics. Often you will find legacy systems have capabilities that are tightly coupled to additional data or processes that might need to be refactored. In those cases look to identify business rules and place them separately for reuse.  If legacy system needs data asynchronously publish standard messages and have the legacy system subscribe to them. Avoid one-off point to point integrations as much as possible and you will significantly increase the level of reuse
  3. Integrating business processes with data services – look to reuse data services for managing your core data entities. Services may not always exist and it is tempting to build project specific services but you should resist that and strive to build standardized services. If necessary refactor existing services, plan a migration path for your existing consumers, and build towards reusable service capabilities.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


Create a standard event processing infrastructure

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.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


Communicating Reusable Software Assets Podcast Episode

June 7, 2009

Want to listen using iTunes?

Using iTunes?

podcast

The newest episode of the software reuse podcast series covers key communication themes/concepts and the communication plan artifact.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


%d bloggers like this: