SOA Best Practice for Business Unit Alignment

Best Practice SOA with Business Unit Here's probably the first best practice you should put into place when building a SOA:

Build a SOA with the business unit!

Here's what I mean. I keep seeing IT groups defining and building a SOA without engaging the business unit. Who, by the way, is their customer.  An example is an IT group building a SOA common services infrastructure (management, registry, policy, etc) as a set of services for the business unit to run their applications. But, they are building it without the business unit. Which leads me to:

Build a SOA without the business unit and watch them \*not\* come!

Seems so obvious, but it really isn't. IT groups have grandiose plans as to what infrastructure services they will provide and build  without even really knowing what the business unit needs. Why build 101 management features into the management service if the initial business unit application only needs 3.

Don't get caught in this trap. Get the business unit involved from the start and build the services based on their requirements. And most importantly:

Build the SOA incrementally!


I concur, John. Where I've witnessed customers taking the "build a SOA infrastructure and they'll come" approach, its failed due to a lack of compelling business value to convince the business unit IT "customers" that their investment in an as-yet unproven architectural approach is warranted. The SOA successes I've witnessed, OTOH, involved a true business-IT partnership, technology-for-the-sake-of-business instead of technology-for-the-sake-of-technology. IT can drive the process by educating one or more receptive business execs on the value proposition, then jointly identify a candidate business service that shows great potential for lower TCO or reduced Time To Market (TTM). The key to gaining momentum with SOA is to prove out the concept by showing meaningful, measureable ROI with one or more pilots, then use that success to justify a cross-org initiative that's championed by the executive suite.

Posted by Jon Hansen on qershor 20, 2005 at 10:20 PD EDT #

I agree - SOA is a business operations strategy for leveraging technology. Business should absolutely be involved in defining the business and IT strategy as well as prioritizing the various projects for delivering business solutions. SOA requires some up front investment in infrastructure which requires business buyin - for funding purposed but they need not be involved in the technical aspects of how it is implemented. IT orgranizations should be solely responsible for the delivering the infrastructure - with oversight from the busines. Hmm!!! reminds me of our form of govenment :).

Posted by Yogish Pai on korrik 25, 2005 at 11:01 PD EDT #

I work for a large enterprise looking at adopting Service Orientation. A heated debate that we've been having here amongst the architects community is how to broach Service Orientation (and NOT Service Oriented Architecture!!) with the business. I believe that in order to achieve successful adoption and realize the ROI, without further confusing the business further (I saw glazed looks when a vendor attempting to introduce this concept to the exec. mgmt started using words like UDDI and Web Services), we need the following approach: 1. When a business unit specifies business requirements for a particular solution, there is a need to start thinking in terms of Business Processes that naturally lead to Service discovery. (top-down approach) 2. IT needs to take stock of the IT portfolio to look at existing IT investments that need to be leveraged for realization of the business processes. This may require setting up of service wrappers to expose the functionality to the business unit (bottom-up approach) 3. Identify re-usable infrastructure services that would support business processes to become more agile and flexible and be able to react to change in the business environment. These include services such as authentication, authorization and information access services (e.g get tracking Id) 4. Build a canonical model of the information that represents the business unit to allow for diffenrent service end-points to use as a transformation model and ensure consistency in the representation of key business information. As far as justification for upfront investment from the business to setup an integration infrastrucute that implements a subset of features that are supported under the ESB architecture pattern - I am not sure how a business can be convinced that this time their investment will not go waste as compared to the previous IT investments that they have been involved in. :). My 2 cents worth. Regards vp

Posted by VP on shtator 30, 2005 at 07:58 PD EDT #

SOA - hmmm.. I am not sure that I get it? I have been a software architect for many years and thought a SOA is simply a modern “type” of software architecture design. Just like we have monolithic, distributed and other architecture type of designs.

See Service-Oriented Architecture (SOA) – the Truth

Now how to apply SOA or any other architecture design to a business unit?, is a completely different story and is independent of the term SOA. Here you are dealing with business people that would have no idea what SOA meant or why they should care. The discussion needs to be in terms of cost, labor, schedule time, ROI, risk mitigation, politics, ownership, crossing functional boundaries, etc., not a technology discussion. And yes, of course, gathering requirements, which has what to do with a SOA?

I have been involved in 25 SOA projects over the last 5 years and when talking to business folks about implementing technology (of whatever kind), they are interested in hearing what it can do for them, how much it will cost, etc., but never do they say, So Mitch, what about this service contract, should we go elements or attributes? :-) Cheers, Mitch

Posted by Mitch Barnett on tetor 25, 2005 at 12:22 PD EDT #

Thanks Mitch. Biz folks don't care if you use two cans and a string to help them get to market faster and cheaper. We need the business units to drive the requirements of our SOA solution. IT provides the services and service processes which provide the infrastructure necessary for the business units to build composite applications quickly and less expensive than pre-SOA.

Posted by John Crupi on nëntor 01, 2005 at 02:14 MD EST #

Post a Comment:
  • HTML Syntax: NOT allowed



« korrik 2016