Partager via

OSF 8: Building a People-Ready SOA (Service Oriented Architecture) via OBAs

  • Article

[OBA Solution Framework Index]

I'm posting this from Singapore where I did a couple of sessions at their Strategic Architect Forum yesterday on Office Business Applications, composite business solutions, and how to build them. 

Lately a number of folks that I've talked to, have been wresting with the practicalities of building a SOA (Service Oriented Architecture). While SOA holds a lot of potential, there have been a number of large SOA projects where benefits have not been in line with expectations. This is especially true of Big Bang SOA, where large re-engineering projects have been kicked off. InformationWeek in an article here points out some troubling statistics with Big-Bang SOA (e.g. 24% projects short of expectations, 41% projects with cost overruns AND failure to meet expectations).

I think that usually SOA failures arise due to inadequate consideration to how real people will use the system. There is an inordinate emphasis on building 'perfect services' rather than supporting the decision making processes of information users. So lets see here, what a "People-Ready SOA" might look like.

I once met with a large semiconductor company that wanted to introduce a new kind of product to market. In about 18 months they had retooled their manufacturing facilities to make these, and set up new sales & distribution channels. However at that time, their IT systems were still nowhere close to being able to take orders for the new product, plan production and then drive their manufacturing execution systems. They had a familiar problem - legacy business applications that were monolithic - that prevented change rather than enabling it. It was hard for them to build new cross-functional solutions.

The problem is that most applications are architected in isolation, and offer few opportunities for reuse. For example, let us assume that you have systems that look like this.

So you now want to unlock business value through SOA. Usually business justification for this is some combination of the 3 A's (Agility, Alignment, Adaptability) - see paper by Dr. Hau Lee on this topic. For me, this translates to the ability to quickly and easily build new cross-functional solutions to keep up with business needs.

Let us suppose that you now start to build a SOA. The first thing to watch out for, is to avoid the following (very common) mistake. You've replaced applications with services - but you haven't actually improved anything. Although for your troubles, you have introduced more complexity through a new technology stack.

 

So you might next want to refactor services for reuse, as shown in the next figure below.

This leads to a new kind of problem. No matter how cleanly you design your services, it is hard for business folks to relate to them. Have you ever tried explaining an API, or a WSDL doc, to somebody in the business? Also, you want to separate out things that change frequently from things that don't. In other words you want to externalize the points of variability in the system, so that they can be changed easily without long drawn development cycles.

So you add in a business process management tier next. This is a set of technologies that let you design and orchestrate interactions across services. The advantages of doing this are:

  1. Visualization of process - visual representations of business processes that are first class citizens of the development process, rather than dusty documents 
  2. Align IT resources to business imperatives - if business processes are made explicit, then it is much easier to align IT resources with business needs 
  3. Monitoring - explicit processes enable monitoring of activities, which leads to oportunities for optimization and improvement
  4. Enables change - it now becomes much easier to change processes and / or the business rules that drive them. The idea is that changes to core services are made relatively infrequently, and are done incrementally when needed - most changes are made in the process tier (if services and process tiers are designed correctly).

But there is a problem with doing this, as shown below.

Usually BPM tools work best to handle automation of services, processes and systems. However people and computers don't work in the same way. People need an environment that is flexible and dynamic, that can handle unstructured information and documents, and that allow them to easily change the way that they receive and consume information. Computers deal with structured information and processes.

So you need to design an environment that enables collaboration and human decision making. Neither of these come from the services tier, or the process tier - which mans that you have to explicitly account for this in a separate tier as shown next.

What are the capabilities, that need to be delivered by this collaboration tier? Some of the capabilities provided by SharePoint - which is a good fit for the collaboration tier are as follows:

  1. Self service content management and BI - ability for users to create, store and share information e.g. documents, lists, reports, wikis, blogs, etc. with versioning and security.
  2. Security - ability to partition information by process, role, organizational hierarchy etc. - and set up appropriate access rights.
  3. Portal - this provides a customizable / personizable interface for users to publish information, and to search for information. Users have the ability to compose project / role / activity specific pages, sites, and dashboards. Emphasis here is on "employee self-service".
  4. Solution services - forms services to easily create and deploy forms, and Excel services to turn spreadsheets into server side components for reporting, calculations etc.
  5. Communications - track inbound emails for archival, send outbound emails for alerting / notifications, integration of portal to real time messaging channels.
  6. Connections to lower tiers - back end data, services, and structured business processes. These connections are set up by IT, with role specific access controls. Once set up, the connections can be used to access information in the portal, e.g. in reports, documents and dashboards. 

You may notice that I have chosen not to consolidate at the data or presentation tiers. The architecture should allow for federation of data, allow for composition at the presentation tier, and support multiple channels of information consumption.

What are the implications of this architecture? Well firstly, you need to choose a platform that supports this kind of decomposition and assembly. Not coincidentally, the five tiers here match up with the five tiers for an OBA here. So the platform for building an OBA will deliver all elements of a "People Ready SOA".

Once that is done, the architecture will provide the following benefits:

  1. Separation of concerns
  2. Loose coupling
  3. Patterns of reuse
  4. Enables composition
  5. You don't need to write code for everything

Comments

  • Anonymous
    May 22, 2007
    [OBA Solution Framework Index] Let us say that you've decided to build an Enterprise Architecture that