Benjamin Moreland, Director for Foundation Services, The Hartford
Mohamad Afshar, VP of Product Management, Oracle
SOA has reached a point where organizations are optimistic about the promised benefits of SOA and are starting to implement SOA based projects. Yet SOA is a broad set of concepts that will influence an organization and its activities beyond one project, thus the frequently asked question: “What are the activities and best practices for a successful SOA implementation?” To realize the promised benefits of SOA, an enterprise must progress and build capabilities in multiple dimensions such as architecture, infrastructure, organizational culture and alignment of people and processes, information and analytics capabilities, governance, techniques and utilize standards-based tools.
This 3-part series, The Path to SOA, puts forth a realistic business and technology view of what it takes for companies to successfully adopt SOA at what we have deemed Level 5. What is Level 5 SOA? Level 5 SOA is the final level of SOA capabilities in our model and represents the ultimate state of SOA within an IT environment. Within Level 5 SOA, applications and systems operate as optimized, automated and self-adapting control systems for the business. Each system has complete flexibility to continuously adapt in real-time, based on user direction or automated response to business performance measurements.
Each part of this series covers activities necessary to achieve Level 5 SOA: Part 1, Assessment, outlines how to identify existing capabilities and future goals; Part 2, Project Selection, describes how to chose the right projects to achieve your goals; and Part 3, Planning & Execution, summarizes an SOA specific methodology for implementing those projects. Together, these will enable you to formulate a long-term strategy for introducing and leveraging SOA, assemble the planning pieces to achieve your goals and successfully execute SOA projects.
The Path to SOA, Part 1: Assessment
This is the first part in the three part series on The Path to Level 5 SOA, which puts forth a realistic business and technology view of what it takes for companies to successfully adopt SOA. We discuss Assessment and outline how to identify your existing capabilities and future goals to help drive your SOA adoption.
SOA Maturity—Why Care?
A maturity model is a “handbook” for process improvement. When you look across organizations, you see that there is a wide level of commonality in the generic capabilities. These commonalities are captured as maturity levels in a maturity model. A service-oriented architecture (SOA) maturity model serves as a means for you to understand the capabilities that are central to a successful SOA, and a tool to help you chart your SOA plans. It also serves as a mechanism for you to start equating IT investments with business benefits while managing risk—since each increasing level of maturity has investment requirements and brings increasing benefits. The nature of any maturity model is that there is no right or wrong approach—any model is a framework that provides a set of benchmarks, which may be helpful to your organization in developing your own approach.
SOA is a journey and when you embark on a journey, you need to have these aspects covered:
A Starting Point and a Checklist—Understand where you are starting out from and what you need to get you to your destination.
A Destination—Know where you are heading. Have an end goal in mind!
Milestones—Identify milestones on the way to your destination and make sure you measure progress as you go.
We have developed a maturity model called Level 5 SOA Maturity Model based on extensive experience working with customers and partners. The model takes a holistic approach to SOA success.
But what exactly is Level 5 SOA? Level 5 SOA is the final level of SOA maturity in our model and represents the ultimate state of SOA within your IT environment. A combination of the right organization, processes, and technology, it represents SOA at its best, providing the maximum level of business benefits to your organization. It’s a vision and we aim to help you get there!
How Do You Use a SOA Maturity Model?
Take a maturity model, such as our Level 5 SOA Maturity Model, and assess your maturity against its capabilities, keeping in mind the following:
Your Level of Maturity—Select the level in the maturity model where you want to be based on what your business needs.
Milestones—Note any relevant benchmarks.
Intermediate Maturity Levels—Note key intermediate maturity levels on the way to your end goal. Based on the end goal and the intermediate maturity levels, chart the key decisions and the related policies that are required for you to address the major capabilities that you need to put in place to ensure success. Put these into your plans!
Background on Maturity Models
We trace back the SOA maturity models to the CMMI (Capability Maturity Model Integration), which is a frame of reference for IT process improvement. The model outlines five levels of maturity— Initial, Managed, Defined, Quantatively Managed, and Optimizing. These classifications denote increasing levels of process predictability, control, and optimization, going from unpredictable processes that are somewhat ad hoc to processes that are subject to continuous improvement.
Although our Level 5 SOA Maturity Model is based on the CMMI model in spirit, it goes beyond existing maturity models. More specifically, it considers SOA maturity as being dependent on a range of capabilities covering infrastructure, architecture, people and processes, delivery, information and analytics, and governance—not just technology and infrastructure, which is the basis for many maturity models.
Our Level 5 SOA Maturity Model gives decision-makers a holistic framework to identify their current state of SOA capabilities across their architecture, infrastructure, information and analytics capabilities, people and processes, and governance.
Level 5 SOA Maturity Model
The Level 5 SOA Maturity Model has five distinct levels of SOA maturity, including Level 1, opportunistic SOA, which is about doing a few quick win projects, and the top Level 5 SOA, which is about delivering on the vision of real-time enterprise that is integrated internally and with partners, and that can capitalize on new opportunities and where IT can deliver the agility demanded by business – i.e., nirvana!
Each level is primarily designated by a vision and strategy, and has associated benefits. A company may start out on the road to SOA with a Level 3 vision; that is, strategic business automation and transformation. In this case, our advice is to consider implementing some of the best practices captured at Levels 1 and 2.
Opportunistic—This is where there is limited experience with SOA. Quick win projects to show value and get experience have been completed. Learning and planning take place; for example, building a few services and exposing them in a portal.
Tactical—SOA is being applied tactically to existing project portfolios, probably across departments. Projects include integrating customer data across a few systems. A portfolio of services starts to appear with some reuse.
Strategic—Strategic business automation and transformation. Focus is on automating manual business processes and integrating systems to drive strategic business change; examples include integrated work order management.
Enterprise—Automation is largely complete and the emphasis has moved to monitoring and measuring with a view to enabling continuous improvement in business processes. A typical project is layering Business Activity Monitoring (BAM) on top of an existing business process to monitor service-level agreements and help drive improvement.
Level 5—The IT infrastructure is SOA, and business insight and automation go hand in hand to deliver continuous automated business improvement. Business is self-optimizing through automated feedback loops. Demand forecasting and supply chain execution systems are integrated to drive efficiency, tighten product cycle times, and increase inventory turns.
The Level 5 SOA Maturity Model is shown graphically in Figure 1.
Figure 1: Level 5 SOA Maturity Model
In the Level 5 SOA Maturity Model, we have captured projects that are typically attempted at each level. We are not necessarily recommending doing less-complex projects at earlier levels. By designating a level to a particular type of project, we relate the critical success factors and capabilities for that level with the types of projects that can be performed at that level.
Key Determinants of Maturity
What are the key capabilities that determine SOA maturity? Is it number of services? Number of service consumers? Total number of service calls per day? Number of SOA-trained developers? Architectural adherence to SOA? Adoption of governance principles to drive SOA adoption? Organizational structure? Availability of high-quality information and analytics? Use of a formal SOA methodology? Use of agile development processes? Or could it be infrastructure and tools? Or buy-in from the CTO? CIO? Lines of business? CEO? Our view is that all of these factors are relevant in assessing the maturity of an organization with respect to SOA.
Here are some of the key determinants of maturity that should be evaluated when assessing maturity with respect to SOA:
Strategy: As the established adage goes, “Think strategically and act tactically!” Successful SOA at each maturity level requires a strategy and vision.
Infrastructure: A focus on incrementally building out SOA infrastructure is key to any SOA strategy, as is using standards, defining your own variations on those standards, and enacting them as your corporate standards. There are key infrastructures and relevant technical and vertical industry standards that you should be using at each maturity level. You could use any of the more-advanced infrastructures at any level; for example, you can do complex event processing when starting out at Level 1. However, it’s a required part of your SOA architecture and solutions at Level 5, industrialized SOA.
Architecture: SOA is about architecture (the A in SOA) and architectural evolution! Hence architectural planning is a key part of SOA maturity. Key aspects that indicate architectural maturity include service portfolio planning; basic enterprise technical standards; presence of an enterprise architecture group; adoption of SOA reference architecture(s); guidelines on the development of reusable services; and policies for service management, performance, and security.
Information and Analytics: An often-ignored part of SOA is information architecture and the use of analytics to help drive business improvement. Having good information on tap and widely accessible predictive analytics is key to achieving the vision of Level 5 SOA, and should be part of any SOA and strategy.
Governance: Unfortunately, governance is an often-misrepresented term. Peter Weill of MIT defines IT governance as “specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT.” Decisions and policies are the means by which you influence the desired behavior that contributes to successful SOA. Key decisions need to be made at the enterprise level regarding the evolving application portfolio (because your applications are a good source of services); business services portfolio; ongoing investments in infrastructure, tools, and applications; project portfolios (services are typically sourced from projects); architecture (you have to plan your architectural evolution to SOA); and operations (sharing has widespread interdepartmental operational implications). This is what governance is about. Policies cover such aspects as investments to drive SOA; incentives to encourage reuse; and governance of interfaces, versions, and service-level agreements (security, reliability, performance) for shared services that are reused. The latter is usually termed service governance and is a subset of the larger governance picture. We are not suggesting that you put in extensive governance schemes when you start out—just realize that SOA requires change and change happens through decisions and policies.
Management: There are three aspects that we roll into the management category—people (including elements like education and organizational aspects), processes, and delivery (the way you develop software). Typically IT organizations are in silos that are aligned to lines of business and corporate IT. SOA is not just about breaking down IT silos, it’s also about breaking down organizational silos. Factors such as alignment of personnel with your SOA reference architecture; a process for ensuring managed service evolution; a process for funding services; an operational model for services; a mechanism to measure and improve service reuse; a presence of SOA center of excellence; SOA and business process management training for IT; and application of a SOA-friendly development methodology are all key determinants in assessing SOA maturity.
What’s the Use of a SOA Maturity Model?
Helps in Selling SOA to Business and Enables Greater Accountability in Technology Investments—With increased levels of maturity and SOA investments, there are increasing business benefits. Business can decide the level of maturity that it requires and engage with IT to deliver it. Hence, the maturity model and assessment serves as a mechanism for equating IT investments with business benefits.
Is Beneficial for Architecting a SOA Adoption Plan—A SOA adoption plan needs to include technology infrastructure, IT investments, organizational changes, and governance with SOA. By performing a maturity assessment, you can derive the key actions that you need to take to flesh out a range of capabilities on your SOA road map that covers all these factors.
Provides a Means of Measuring Progress on the Road to SOA—SOA is about change, and as you progress on the road to SOA, you need to check how much progress you have made and adjust your course accordingly. A maturity model can help you evaluate where you are at any point in time (not just at the start of your SOA journey), and make decisions and enact policies that drive your SOA adoption to where you want to be.
A SOA maturity assessment gives insight into an organization’s current capabilities for executing SOA projects by collating best practices into a format that can be consumed incrementally. So use it as an integral part of your SOA planning process. In part two of The Path to Level 5 SOA series, we will discuss the importance of project selection.
*Editor's note: Kevin Clugage is also a contributor to this article. He is a
product director for Oracle Fusion Middleware. His focus areas include BAM, BPM
and SOA. He has a degree in electrical engineering and computer science and an
MBA, both from the University of California at Berkeley.
About the Authors
Benjamin Moreland is presently employed at The Hartford as the Director for Foundation Services, which is responsible for the realization of The Hartford’s P&C SOA direction. He has over 20 years of IT experience that includes management, research, presentations and development, with a strong background in artificial intelligence. In the last 3 years at The Hartford, his team has implemented over 80 services, deployed a UDDI registry, SOM, service bus, BPEL and helped set the SOA standards for The Hartford. He has presented at numerous conferences. While at United Technologies and The Univ. of Conn., he led and participated in many research and development efforts. Mr. Moreland has a BA in mathematics, and an MS in Computer Science & Engineering from The Univ. of Conn.
Mohamad Afshar PhD, is Vice President, Product Management within the Oracle Fusion Middleware development organization. His main focus includes vision, strategy, and architecture, with an emphasis on SOA, EDA and next generation. He works closely with customers advising them on their SOA roadmaps and has spearheaded Oracle's SOA Methodology. Previous to Oracle he was a co-founder of Apama, an algorithmic trading platform (sold to Progress). Mohamad is a frequent speaker at industry events and is a contributing author to business-oriented, technical, and academic journals. He holds a PhD in Parallel Database Systems from Cambridge.