SOA is mainly concerned with a set of best practices that have been around for some time, and that will most certainly stay valid for the foreseeable future. The implementation of these best practices depends on the current state of technology, and this will vary as new technologies come around.
Talk to a CEO about SOA and chances are you will be frowned upon because of all the perceived hype – and they might actually associate SOA with ‘Stupid Over-hyped Acronym’.
In reality, business managers don’t care about labels; they just want their businesses to grow and the shareholder value to rise. This can be achieved by working more efficiently, streamlining business processes, enabling re-use and a constant focus on the real differentiators within the company’s offering.
Businesses must have a clear understanding of how the business is running, and preferably have a Business Component Framework to hand, detailing all the different business components making up the business processes (see Figure_1).
Figure 1: Business Components model
Growing a business involves innovation: businesses need to constantly innovate, and some innovations will mature into mission-critical activities (core competencies) for the organisation. After time, core competencies turn into commodity or overhead (context), and ultimately the initial innovation is retired. This is unfortunate, because along with the retired technology some valuable business knowledge goes over the cliff. If we succeed in abstracting ‘intent’ from ‘application’, the extracted functionality can be reused for supporting new innovative business processes. This is summed up in Figure_2, which is adapted from an image from Geoffrey A. Moore’s book, Dealing with Darwin, published by Capstone.
Figure 2: Making the most of innovation
Now doesn’t this sound like a neat idea? It actually is… but setting up an architecture which renders this reuse possible is an extremely challenging feat for most businesses today. Typically organisations are stuck in a ‘stagnation’ phase in which the tightly coupled application architecture is difficult to adapt without causing changes in dependent systems. In order to become more agile, organisations need to start thinking in terms of ‘Loose Coupling’, an architectural setup in which applications are not linked to each other with Enterprise Application Integration (EAI) links, but by means of standardised message exchanges.
So where do you start? At all costs, try to avoid the ‘Big Bang’ situation. Make sure you have a vision, and adopt a phased approach – often called a SOA roadmap – charting a course of where you are today and where you want your organisation to be within five years time.
By incrementally implementing SOA’s best practices, the organisation will gradually evolve towards the vision. Choose a realistic pilot project (keep it simple!) and make sure the pilot’s results get plenty of visibility within the organisation. Just extracting customer data from a mainframe based upon an ID might be a good choice.
To get a successful SOA show on the road, the following key elements will invariably be needed: services, repository, enterprise service bus, front-ends, governance and methodology.
Services are unsurprisingly mandatory for a SOA. They should be classified into different categories in order to ease the implementation strategy, code reuse and management. To ease reuse of the services, they should be put into a repository.
Many vendors will argue they have a ‘repository’ available and then introduce Universal Description, Discovery and Integration (UDDI) as the all-encompassing solution. You should be aware that UDDI is just the technical side of things. Bear in mind that the main purpose of the repository is to bring together business components and technical services, and how they relate to each other.
An Enterprise Service Bus (ESB) connects all the participants of the SOA. It is mainly about connectivity, transport, routing and transformation. Often a source of confusion, the ESB indeed suffers from a lack of standardised definition. To make things worse, many ESB products’ features overlap with certain areas within a typical integration tool (for instance BizTalk orchestrations; Oracle BPEL Designer) – see Figure_3.
Figure 3: BPEL process inside Oracle JDeveloper
For a typical pilot SOA project, you start out with some basic services, and access them from an application front-end. Application front-ends are mandatory – no service will start delivering its functionality on its own without a trigger. The application front-ends trigger the business logic and ultimately receive the results.
Take governance seriously. Set up a governance board consisting of a number of people with diverse backgrounds that have been with the company for a considerable amount of time. They will act as a quality gateway for the services in the repository and drive the improvement processes. Corporate governance is about establishing measurement and control mechanisms to enable people to carry out their roles and responsibilities (see Figure_4).
Figure 4: Alignment vision for the future
If we need to measure the effectiveness of people working together, rate the quality of artefacts produced, and streamline time to market, a good development methodology will prove beneficial. Choose an approach that is iterative and incremental such as the Rational Unified Process (RUP) and customise it for your specific project.
Any SOA initiative should be business driven. IT-driven SOA initiatives often turn out as a ‘shiny new toy projects’ – without tangible business benefits. But the business is often the party most difficult to convince of the SOA benefits. So have your troops lined up before taking your SOA plans to the management.
Be realistic about where your organisation stands today. It’s easy to be fooled into thinking you have a fully-fledged Service Oriented Architecture running just because a workflow tool has been installed on one of the servers, or because you are already using Web Services.
SOA is unavoidable; it is happening right now – and many organisations are seeing tremendous benefits from it. Realising that it really is a shared effort between Business and IT – working towards a better understanding of each other – will bring you one step closer to success.
JB International, based in London, was founded in 1994 and its team of technical consultants provides hands-on training in technologies such as .NET (2.0 & 3.0), Java, SQL Server 2005 and Oracle 10g; and Business Analysis and Intelligence, for Software Developers, Business Analysts, Project Managers and Technical Architects. Visit for details of its range of public, on-site and customised courses.
Comments