ITIL Services

ITIL Services are different from Services Oriented Architecture (SOA) Services. The Information Technology Infrastructure Library (ITIL) is an accepted standard for operational IT issues such as incident management, problem management and change management. ITIL builds up a large set of terms and tries to use these terms consistently throughout its discussion of Service Management.

The conflict over the term "service" can lead to some confusing conversations between developers and operations staff. I have posted earlier on the definition of services in SOA. The ITIL definition is

"A service is a means of delivering value to customers by facilitating outcomes
customers want to achieve without the ownership of specific cost and risks. "
ITSMWatch

Two very different examples of a service in ITIL could be a payroll system and the resetting of a LAN password. The services of an IT organization should be available on a "service catalogue" and the clients of the IT organization can use this catalogue to choose and understand the services they receive.

This is different from an SOA service. An SOA service 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.

The main difference is that an SOA service is a software component in SOA. It is not the service that a help desk provides when they reset your password and it is generally smaller than a whole payroll system. An SOA service can be hidden away from the users in the cloud of application components. Ideally it is granular enough to have meaning to users but a user does not need to be able to interface with a service directly.

There can be coincidental overlap between an SOA service and an ITIL service. A service for paying a bill may also be presented directly to the users of an IT Department or organization and therefore be a service on their catalogue. This only seems to confound the issue. It is safer to assume that ITIL stalwarts and SOA engineers are talking about different things when they refer to a service.

IT Service Management (ITSM) under ITIL however can provide an appropriate means for providing governance for your SOA and for providing the operational platform for your SOA. SOA may contain more component parts than traditional systems and a disciplined approach to configuring, operating and changing these parts is required which is exactly what ITIL offers.

Interestingly ITIL also seems to redefine SOA as "Service Offerings and Agreements" and "Service Outage Analysis" which also makes life complicated.

Notes:
Some good articles on ITIL and SOA follow:
http://www.ca.com/Files/WhitePapers/soa_wp_jlong_33146.pdf
http://www.ibm.com/developerworks/ibm/library/ar-soaitil/
http://www.ebizq.net/blogs/bethgb/2009/03/can_itil_help_fix_soa.php
http://www.biske.com/blog/?p=467

The book I am reading which proffered the payroll as a service example is:

Klosterboer, Larry, 'Implementing ITIL Change and Release Management', IBM Press, 01 Dec 2008.

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.

Understanding Enterprise SOA: Book Review

I was handed this book by one of my programmers. He lent it to me because he knew I was doing some reading on the subject and trying to work out how to bring my software developers up to speed with SOA. I didn't get the impression that he had got terribly much from the book himself. After reading it I can see there is benefit for managers but I think there was not enough technical meat in the book for programmers and analysts.

This book is not technical. It can be read by managers, salesmen or students and I think these were the intended audience. The explanations are easy to understand although I found them long-winded and overly simplistic on many occasions.

The authors attempted to explain procedural code as if it was museum artifact. This made me feel very old. It begs the questions whether the developers brought up on object-oriented development and SOA really need a detailed explanation of the concept of procedural code.

On the positive side this books tackles issues that others do not. It has a good non-technical discussion about security issues and there is a lot of discussion about human issues such as training, reorganization and corporate culture.

Oddly for a book written in 2006 I did not find any mention of Enterprise Service Bus (ESB) although it was clear the author was encouraging looking at off-the-shelf SOA management solutions as well as SOA security and routing software.

Eric Pulier in his preface is unbridled in his enthusiasm for SOA standards:

In a spectacular cycle of enlightened self-interest, every major company in the world has build on top of standards which have ushered a potentially exponential release of value from investments in information technology.

Elsewhere in the book there are sufficient cautions to temper this enthusiasm. In particular the authors advise that much of SOA is still hard work and that there are no industry standard solutions to problems such as transaction processing and security.

There is a long and detailed case study running through the book. The authors do not hold back on the multitude of issues that confront an organization adoption SOA. Parts are realistic and even painful for those of us who have been through implementations of a difficult project or technology.

The book has a good history of technologies and standards. The authors make a good point about standards conforming to the Tipping Point model (see references below). This is when a standard reaches a certain level adoption that it suddenly becomes desirable for the majority of developers.

This is not a strong academic text. There are not many references to other information sources. The definitions are not clearly stated and often over-simplify the concepts. Concepts like Enterprise Architecture, Real-Time Computing and loose coupling are all not accurately defined.

"Loose-Coupling" is described but not adequately explained. The authors give the impression that loose-coupling is only about where you can locate services.

Web services, in contrast are loosely coupled. Once a piece of software has been exposed as a web service it is simple to move it to another computer.

This is an important aspect of coupling but is not the whole story as I have identified on previous postings.

The book focuses on synchronous services rather than asynchronous services. This is unfortunate as other texts such as Thomas Erl or Krafzig, Banke & Slama seem to advocate asynchronous services.

The book addresses the Subject of Enterprise Architecture again loosely defined. At one point the book states

There is no institute providing credentials for enterprise architects.

I'll give the authors the benefit of doubt. Perhaps in 2006 there were not the credentials around but these days there are a number of places to get recognized credentials as an IT Architect. The Microsoft Certified Architect programs spring to mind although I will not vouch for the content of these programs.

The authors see SOA as a method for replacing parts of the Data Warehouse. I was not particularly convinced by this. This was an interesting subject which I had not seen before. I think there is benefit in moving the content of SOA logging to the data warehouse but I was not convinced that SOA radically changes the typical data warehouse ETL process.

This is not a book with detail examples of SOAP and WSDL. It will not explain how to code or build services. You will not find much detail on WS-* here either.

Contracts and Service Level Agreements (SLAs) are described in the book. The authors also introduce the Business Level Agreement (BLA). This is agreement to monitor business conditions such as an inventory pile-up causing $100k per minute of cost.

The book is well illustrated with copious diagrams and notes attached to the diagrams. I found myself skipping past a lot of the diagrams because they did not seem to be explaining anything particularly special.

I congratulate the authors for including detail about setting up training programs in the book and explaining how the resources are brought in to deal with the adoption of SOA. This is missing from many other texts and is an important issue today.

The authors emphasize that SOA is an enterprise approach. Under SOA, IT departments put in place infrastructure to serve the enterprise rather than just serving particular applications.

I would recommend other books before this one for most audiences. The simplistic and at times pedantic prose would make it hard to recommend to an IT professional. Nevertheless there are some well-made observations in this book that you are not likely to find elsewhere.

References

Understanding Enterprise SOA, Eric Pulier and Hugh Taylor with forward by Paul Gaffney, Manning, 2006

The Tipping Point: How Little Things Can Make a Big Difference (ISBN 0-316-31696-2) is a book by Malcolm Gladwell, first published by Little Brown in 2000.