Getting Organized for SOA Success Part II

July 9, 2009

In the previous post on getting organized for succeeding with SOA I talked about the importance of implementation-free requirements and the overall role of business analysts. In this post, I would like to highlight specific areas where business analysts can help SOA initiatives.

  • Create business models – free of technical specifications or system level details – that capture the full end-to-end view of a business process. They should use a modeling tool that can work with a standard notation (e.g. BPMN) and create as accurate a view of a business process as possible. They need to capture human steps, system steps, pauses, business rules, external activities, etc. accurately and comprehensively
  • Identify candidate business capabilities – not necessarily technical services – but at a higher level of abstraction. For example, MakePayment or BookTicket are business capabilities that can be realized in a multitude of ways by technology folks. But the analysts could significantly help by pointing out capabilities that are candidates for reuse across multiple business processes, scenarios, or lines of businesses.
  • Identify areas for simplification/streamlining – analysts can identify redundant manual steps where users enter data multiple times or in similar fashion. They can also identify steps that can be eliminated or made simpler. For instance, validating credit worthiness of a customer could be done systematically and the system can present options for the user based on score. Or the credit worthiness score could be driven by business rules and only in exception cases the system might require manual intervention. All these behaviors have to be driven from the context of how to make the overall user experience better.
  • Provide context – analysts can help identify areas of business priority in order for technology to build services. What lines of businesses are meant to grow? which ones are going away? which business process needs maximum customization and if so, in what ways? A good analyst can provide the big picture view, the context for your SOA initiatives by helping you separate the essential from all the noise.

This list isn’t exhaustive but is meant to give a sense of the key role that an analyst plays!

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

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


%d bloggers like this: