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

Advertisements

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


%d bloggers like this: