OSF 9: How do you start building an OBA? (aka Introduction to Spiking)

  • Article

[OBA Solution Framework Index]

Let us say that you've decided to build an Enterprise Architecture that supports all five layers of the architecture that I laid out earlier - presentation, collaboration, process, services, and data. Let us next say that you've also picked the Microsoft stack as the technology platform for this, and that you have decided to build an Office Business Application. That's great, but then what next?

Let us assume that you start from a set of monolithic applications as below. You are faced with a number of choices now. Do you start tearing apart your existing applications? Do you start to create new OBAs from scratch? Top-down? Bottom Up? You know that there will be a transformation, but will this be business led or IT led? 

One approach is top down - often taken when transformation is business-driven. Here much time is spent on analysing business processes across the company, doing extensive use-case analysis, and then designing OBAs to match. The focus is on designing applications and services to promote re-use. The risk here is that a lot of time / budget might get spent on analysing as-is business processes, without measurable returns.

In companies where transformation is IT-driven, then a bottom-up approach is often used. Here people talk of SOA, but what gets produced are sets of web services that map directly to existing business applications and processes. The risk here is that no new business capabilities, or value, is being created. 

There is a different way - called 'spiking' - where you nail down a fixed vertical scope across all five architectural layers. This scope should be part of a project to deliver a new cross-functional business process that cannot be easily done with existing applications. Next you follow an iterative approach, and at each iteration you expose core IT assets, you compose a new solution from them, and then you plug this solution into information channels easily accessible to users.

Why is this called 'Spiking'? The goal is to get enough breadth in the process, that the solution provides measurable business value. At the same time, there need to be enough depth so that significant architectual / organizational concerns are addressed at each of the tiers. At a high level, the approach for each iteration (or spike) is to do the following:

  1. EXPOSE: standardize core IT assets that make up the solution - e.g. documents that make up the process, business events for that process, data models, performance models, web services for integration to existing Line of Business systems, etc. 
  2. COMPOSE: you assemble the new solution by combining different assets. Composition could be at any of the five tiers, e.g. composing web parts in a portal, or composing calls to business services into workflows that orchestrate them. Here you are setting up the server side information architecture (e.g. site hierarchies, document libraries, workflows, connection libraries and business entity definitions).
  3. CONSUME: you connect the new solution to information channels that are accessible to those roles that make up the process. This means connecting client applications (web based, thick client, Office Client based) to the server side solution that you assembled.

This approach differs from a top-down approach by leveraging the fixed scope of a 'spike' to ensure quick business value, while still mitigating technology risk. This approach differs from a bottom-up approach by ensuring that back end services are aligned with the way that information is being consumed by specific roles.