SOA Definition Revisited

It is time to revisit the definition of SOA. In an earlier posting I provided the following definition and suggested it may evolve.

SOA is a software architecture where the business logic is encapsulated in services and a single application may be distributed over many processors.

A service in this context is a software component which·

• Hides its implementation,
• Is based on standards,
• Is location transparent,
• Is message coupled, and
• Is accessible through defined platform independent
  interfaces.

I recently came across this definition in a book published by IBM Press (see reference below).

A service-oriented architecture is a framework for integrating business processes and supporting IT infrastructure as secure, standardized components—services—that can be reused and combined to address changing business priorities.

Beiberstein et al refer to SOA as a framework I refer to it as an architecture which should be self evident. I do not think this is an important difference. The difference suggests another layer of abstraction a littler further away from the implemented product. The Zachman framework is even more abstract though.

There is an IEEE definition for architecture it is "the fundamental organization of a [business] system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution". I think this sufficiently describes what is needed for an SOA without out going to the next level of calling it framework. I will stick with calling SOA an architecture for now, although I acknowledge that there are a number of technical, logical, and business centric models that should be documented for an SOA.

I like the reference to business processes and I compare it to my discussion of business logic although business logic is at finer grain and is within a service. There is an interesting argument that Business Process Modelling (BPM) should be separated from SOA but generally a good SOA implementation will allow an organization to implement its business process more easily than with other architectures. The BPM tool may be considered to be outside of the services but still be part of the overall SOA. I'll watch this space and consider where I draw my SOA boundary.

Standardize components (services) are obviously central to SOA. I don't think they are necessary secure components. Unsecure services can still be SOA even though it may be bad SOA and security has been a bit of a challenge for the evolution of SOA.

Reuse and combination are important outcomes of SOA but they do not necessarily define SOA.

My SOA definition above is still looking strong. It has the possible deficiency that it uses the term "Message Coupled" rather than "Loosely Coupled". "Message Coupled" is not in wide usage. While "Loosely Coupled" is in wide usage and is descriptive to a point, I found it too loose in my earlier posting and still stand by it.

References
Norbert Bieberstein; Robert G. Laird; Dr. Keith Jones; Tilak Mitra, Executing SOA: A Practical Guide for the Service-Oriented Architect, IBM Press: The developerWorks® Series, May 2008, Page 4.

The definition of Architecture can be found in IEEE Std 1471-2000 Systems and Software Engineering—Recommended Practice for Architectural Description of Software-intensive Systems [2007-07-15]

SWOT on BPM

Toward the end of a problematic first implementation of a BPM solution, I was asked to evaluate whether it was worth pursuing this for future solutions in my organisation. The result was a SWOT (Strengths Weaknesses Opportunities and Threats) Analysis in which I put the case for persisting with BPM. An edited version of this paper follows. While I echo the optimism of vendors for large organisations there some cautions and costs that need to taken into account when embarking on the journey to adopt BPM.


Background
Business Process Modelling (BPM) is a technique for implementing IT systems that makes the process explicit usually through the use of a graphical tool that allows the process to be illustrated as a flowchart. This flowchart can be implemented directly as system of integrated application and services once these application and services have been built.

The process model represents processes of an enterprise, so that the current process may be analysed and improved in future. The development of a business process model is typically performed by business analysts and managers who are seeking to improve process efficiency and quality. The process is implemented by IT staff who may be assisted by BPM tools.

In theory, BPM tools provide business users with the ability to model their business processes, implement and execute those models, and refine the models based on real data. As a result, business process modelling tools can provide transparency into business processes, as well as the centralization of corporate business process models and execution metrics. In practice, BPM tools require significant training and needs users to work closely with other specialist IT staff to implement systems using these tools.

Our organisation has acquired Aqualogic BPM which is being used to redevelop the XYZ system. Vendor X are doing the development work. Aqualogic is new to both Vendor X and our organisation. This has meant both organisations have had to undertake learning in this technology. The project has taken longer than expected. The project will cost more than expected and the support model for this technology has not yet been developed.

This paper will assess the risks involved in moving forward with BPM and advise whether we should continue with XYZ system using the BPM product.

Analysis
When looking at the benefits related to BPM a distinction needs to be made between the BPM process and the BPM tools. Our use of BPM tools so far, has been to reverse engineer the XYZ system and implement an existing process. This is not the most beneficial way to use BPM and therefore will not immediately produce any savings for XYZ system.

More benefits are likely to flow from the revision of the business processes that is inevitable with complicated processes. The mapping and refinement on business process is the same as any continuous improvement initiative.

An effective BPM implementation is much more top-down. BPM is more suited to projects that involve a significant Business Analysis effort. The analysis of the process should be conducted at the business level. The process is then refined and optimised and where possible automated.

Computer Applications are no longer written purely for discrete business units. Modern enterprise applications link different business units with ever more complex processes involving people from all over the organisation. The emerging standard approach for this is to break applications into services (Service Oriented Architect) and link these together using BPM tools. In this way BPM can support large integrated enterprise applications. Along with a portal product and an enterprise services bus, a BPM tool is a central component of the modern SOA development toolkit.

If the right skills and tools are in place, BPM promises to enable a more agile organisation. Conventionally, changing software to implement a changed business process involves editing complicated program code possibly spread over a number of different applications. With BPM the process is presented in a more intuitively obvious form and can be stored centrally rather than spread across different applications. This enables changes and therefore more business agility because of the ability to change these processes more rapidly at lower cost.

Strengths

• BPM allows the process to be viewed and communicated to non-technical users
• The BPM can be changed by staff who understand the BPM tool
• The business process is easier to follow than the corresponding Java code.
• Status can be tracked using the BPM Tool
• Possibilities for process change can be investigated using the BPM diagrams.
• Supports Services Oriented Architecture (SOA)
• Standards-based approach to integrating diverse systems and data sources.
• Engenders Continuous Process Improvement
• Improves business agility

Weakness

• Staff need to be trained to use the BPM Tool
• The organisation needs to pay significant costs to license the BPM tool (including non-production versions)
• There are more points of possible failure in production systems.
  Production systems need to be supported which may will involve extra servers.
• Business process changes normally require constant involvement of the user. (Collaborative development model). This may require more user resource but also a change in software development approach.
• The default process management screens on the BPM Tool may not be appropriate for users. In the case of XYZ system it is costing more to implement custom interfaces.

Opportunities

• We could use the models in the BPM in our Architecture repository and benefit other projects.
• Other projects will become easier to develop using BPM once we have sufficient skills and a critical mass of services that can be used with BPM.

Threats (Risks)

• The organisation may not have chosen the correct tool and this may be replaced by a competitors product in the future.
• The Aqualogic Tool may not be supported by the vendor in the future
• It is possible to map more complicated processes. There may be a tendency to get automated tools to do this rather than simplify the business process.
• There is a performance overhead in running BPM applications. This may cause programs to perform slowly and impact users.
• BPM tool support from any vendor is limited in regional locations.
• If we write custom interfaces for users to manage BPM workflow then we have to make sure these interfaces are compatible with future versions of the tool.
• Outsourcers who have forged a partnership with our organisation will be able to charge high rates to support its BPM tool.

Conclusion
The choice of BPM for XYZ System was sensible from the point of view that the system was automating complicated business processes involving different roles. The decision was not ideal because the project did not require a business analysis stage and an opportunity to refine the business process.

The XYZ system project will therefore suffer the learning curve costs of the BPM Tool. It should also reap some benefits later on for having a process that can easily be modified our organisation retains sufficient skills to do this.

The BPM version of XYZ system should still be implemented. Handover to support should involve making sure there is an adequate support model for the product. This should involve having someone in-house that can support the runtime component of the BPM Tool and assist with the design-time component with the tool.

The investment in in-house skills should be used in other projects. The identification of the potential to use BPM should made early in a project so that the Business Analysis can be done with BPM in mind.

The risks are significant but most can be addressed by acquiring the necessary skills to use the BPM tool effectively. The benefits are also significant. An effective BPM capability will assist build integrated systems effectively and efficiently, and support implementation of a Services Oriented Architecture.

References

Rudden, J, Making the Case for BPM: A Benefits Checklist, BPTrends Jan 2007, http://www.bptrends.com/publicationfiles/01-07-ART-MakingtheCaseforBPM-BenefitsChecklist-Rudden.pdf
Sinur, Jim, The Top Five Benefits That BPM Delivers Today, Feb 4 2009, http://blogs.gartner.com/jim_sinur/2009/02/04/the-top-five-benefits-that-bpm-delivers-today/
Khadye, Vinayek, Benefits of BPM Systems, 7 Mar 2005, http://it.toolbox.com/blogs/bpm-blog/bpm-series-benefits-of-bpm-systems-4837
Cooper, Mark and Patterson , Paul, Business Process Management (BPM) Definition and Solutions, May 2007, http://www.cio.com/article/106609/Business_Process_Management_BPM_Definition_and_Solutions?page=5