Oracle Redefines Middleware

Oracle Fusion Middleware 11g is the first real attempt to integrate the Oracle Fusion suite with the recent BEA products it acquired in 2008. According to Oracle this "Completes the integration of BEA into Oracle".

Oracle seems to be redefining "middleware" to include such things as Business Intelligence, Content Management and Collaboration which has typically been considered user-facing software. At the other end of the software stack Oracle looks at infrastructure services such as virtualization utilities.

"We take a broad view of what is included in Middleware" Rick Schultz of Oracle says on his podcast. According to the materials that Oracle make available, Middleware seems to be defined as a "Set of components that all applications need". This includes

• User Interaction (Web 2.0, RIA, Mobile, Search)
• Enterprise Performance Management (Planning, Budgeting, Scorecards)
• Business Intelligence
• Content Management
• SOA and Process Management
• Application Server
• Grid Infrastructure
• Development Tools
• Enterprise Management
• Identity Management

Depending on the spin, redefining middleware could be a good or a bad thing. I always felt I understood what middleware was. I agree with Wikipedia that "Middleware is computer software that connects software components or applications." To put it more plainly it is the glue that holds together different parts of a computer application and helps integrate computer applications.

The Oracle list is huge, and I suggest Oracle needs to come up with another name for all this software infrastructure (like Software Infrastructure Suite) which does not suggest it is simply the glue that holds the application together. User facing software infrastructure such as Web 2.0 collaboration facilities, Search, budgeting software, score card software and business intelligence is much more user facing than most custom built software. Other products on the list are part of the operating environment. This is infrastructure that the software developer should have little concern with.

This is not to say that the Oracle Suite is a bad idea. We have to accept that with SOA there is far more of an application that can delivered out of the box rather than written anew by developers. True middleware such as the ESB, is still a significant part of the Oracle Suite but the other components also need to be part of the solution architecture. Oracle focuses on some important aspects from the traditional middleware space including:
• Support for SCA (SOA Component Architecture).
• Support for Event Driven Architecture.

Oracle now has a concerted push to explain its offering to the world. This has resulted in seminars and workshops around the world. I attended a couple and they are worth the time to get an idea about what Oracle is proposing. I wish to thank the presenter for the descriptive term "Marketecture" (aka Marchitecture). This term seemed to gain popularity through Dilbert cartoons in 2009, after having some more serious uses back in 2003. Marketecture is the IT architecture as presented by marketing people and therefore has limited detail and may bear little resemblance to the technical architecture.

In conclusion, there seems to be much goodness in the new Oracle Suite. SOA can benefit from a large number of products to support the approach. Oracle Suite is much more than middleware, but Oracle should not try to cover everything under the "middleware" term just because its long list of acquisitions allows it to do so.

Other references:

http://www.dilbert.com/strips/comic/2009-03-02/, Marketect cartoon
http://www.uml.org.cn/success/pdf/marketecture.pdf, Marketecture vs Tarchitecture
http://www.it-director.com/technology/content.php?cid=6173, Architecture Marchitecture (spelt differently but same idea)
http://www.oracle.com/technology/products/middleware/index.html, The list of products in the Oracle Middleware stack
http://www.oracle.com/products/middleware/docs/microsite09-flashmedia-pdfs/fmw11g-overview-solution-brief.pdf, Overview of Oracle Middleware

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

SOA Adoption for Dummies Such as Managers

Software AG has commissioned another SOA publication to "Dummies" series and released it to their customers. This follows on from their "BPM Basics for Dummies" book which was a referred to in an earlier post. I have to confess to listening to the podcast version of this book while watching the cricket rather than reading the book in detail the conventional way.

This book is focused on SOA Adoption rather than SOA. It is not a technical book in SOA. References to XML, SOAP and WSDL are consigned to a footnote. This book is evangelical and pitched at management. I question whether it is right to consider that dummies would be involved in SOA adoption. Your average person involved in an SOA Adoption decision is a highly credentialed senior IT manager on one hand but on the other hand the time taken over each decision of a manager can be minimal and display all the appearances of being made by a dummy.

The authors should be congratulated for taking SOA Adoption as subject in itself as it is a difficult for enterprises to adopt SOA and it is much more than just the technical challenge that needs to be addressed. The book and podcast series are well produced and easy to absorb.

Do not expect any great depth from this book however. The authors call their SOA adoption approach "Rocket Science" but this approach simply consists of:

1. Keep the pointy end of the rocket up.

2. Keep moving up.

3. Don’t stop till you are weightless.

This is good motherhood advice for any significant undertaking but I do not see it as being particularly insightful for SOA adoption.

The authors do a good job of SOA evangelism and have lived up to the creation of simple book for "Dummies" by missing a lot of the technical detail. There is nothing particularly radical in this book but it does give you some important things to watch such as SOA Governance, Organization structure, SOA infrastructure, the SOA competency centre and organization structural issues that might arise from SOA.

In summary, this is a good book to give a dummy or manager who needs to be brought on board to get with your SOA program. It will not get you to SOA weightlessness without a lot of other expertise, skills and resources. It is not the bible for someone wishing to be the main driver behind SOA adoption.

Reference

Miko Matsumura, Bjoern Brauel and Jignesh Shah, SOA Adoption for Dummies , Wiley Publishing Inc., 2009
http://www.softwareag.com/Corporate/res/books/soa_adoption_for_dummies/default.asp

SOA and Cricket

It has been a long while since I put together a blog posting. This has been for a number of reasons both personal and professional. But one reason has been the game of cricket.

I have two sons that are good at cricket and play for a local club. Most of the English-speaking world knows what Cricket is. For the Americans who may read this it is a bit like baseball. You use a bat and a ball and not much happens for long periods of time. Unlike baseball it can be played over several days for up to six hours a day. Much of my time has been involved in watching the game played by my sons but also watching the televised games between the Australian national team and the South African national team.

Progress is made slowly in cricket and it is often not clear whether you are winning until near the end of the game. The players need to stay focused on what they are trying to achieve and there are a whole range specialists (batters, bowlers and fieldsman) involved. SOA is much the same. It takes time. Since my last blog I can report some real progress from my organization but we have still only completed a small part of the journey. We need to stay focused on the desired SOA outcomes and we are gradually building a set of skills and relationships that are required to bring SOA to fruition.

I intend to prepare more blog postings shortly. The cricket season is over and the hot spell in South Australia has passed. Meanwhile my organization has completed a number of projects and has embarked on more which will advance its SOA so I have some content to provide and hopefully the motivation to provide it.