SOAIntroduction Service Oriented Architecture (SOA) is probably the most talked about IT phenomenon of the new century. It is quoted in practically every IT press publication and is often cited as the opportunity for IT organizations to reclaim order from their complex systems portfolio. Conceptually SOA is simply about reusing existing systems or processes in a more manageable way, to build in greater flexibility and remove technological constraints imposed by older architectures. However this is easy to say, not so easy to do: in order to re-use effectively, a full audit of what is available for re-use has to be undertaken, and a low-level examination of system artifacts, processes and source code is seldom quick and easy. The results are therefore incomplete, error-prone and not timely enough. The Yankee Group 2005 Survey arrived at the conclusion that clients should “Make a business process map and create a set of standardized data definitions that will be used to build SOA-based applications” (footnote 1). Micro Focus, long-standing SOA proponents and members of the Web Services interoperability standards body (WS-I), recommend the same approach – taking a full inventory of the current enterprise application portfolio to use as a basis for shaping the SOA design. Using Application Portfolio Management, the move to SOA becomes part of a logical cultural process of managed change, where the risk of failure and difficulty is all but completely removed by a comprehensive initial understanding and fact-based technical decision-making. CIO / Executive The CIO cares about SOA because they or often someone in their team has found that SOA is the means to a business end: the issue might often be one of striving for improved time-to-market, operational efficiencies, organizational agility, but SOA is often seen as the mechanism to achieve this goal. The CIO recognizes the potential value in existing business processes, systems, applications, even transactions, being available as a “service” that can be used, re-used in new innovations, lines of business, servicing new clients with new products. It is likely to be one of the top priorities to turn an SOA “strategy” into a realistic and achievable plan. To reach this point, the CIO needs assurances that the assessment of the SOA objective is based on factual information, carries little or no business continuity risks, and will yield a significant return to the business. Architect SOA and Web Services is quite often a specific operational objective driven by the CTO or Architect office. It is, after all, a technical solution to a business issue. An architectural review is often given as the next logical step in an SOA enablement program – but a full understanding of the IT inventory is only possible through detailed scrutiny of the building blocks of the IT world, namely the source code of the applications that drive the business, as well as the supporting artifacts that support internal business decisions. Access to and assessment of those artifacts must be part of a defined, automated and repeatable process, yielding comprehensible, accurate and timely information. Without this the Architectural Review and detailed results, any plans for an SOA implementation are at risk. Ask any five people “what makes up a service?” and you will realize that you need a scientific discovery process. Technical The technical staff will need to provide the specifics of how what is available today (existing applications etc.) could be repositioned as a service. What exists today requires a full review of the sources that comprise the existing business, defined as business processes and assessed on their value. This level of scrutiny needs technology to assist with the collation and categorization process. Conclusion SOA is a means to an end and requires planning for success. Micro Focus has long been a key proponent of SOA, and the new white paper “Extending COBOL to SOA, Web Services and Beyond: A Look at the Architecture” (footnote 2) explores how Micro Focus’ development tools can assist in the creation of SOA objects from existing systems. The Micro Focus APM solution takes its support of SOA yet further by enabling the best-in-class appreciation of existing systems artifacts in order to decide what can be re-used in an SOA paradigm. Once the assessment is made and an inventory of the business processes is available, the implementation of the SOA plan can begin. But that implementation starts with re-using information found during the original assessment, which should then automatically make existing business processes available as objects that can be published into an SOA world. Micro Focus APM and supporting solutions provides a full journey from discovery to deployment of SOA ‘services’ regardless of the chosen architectural framework. Footnote 1 – Article ‘Momentum Building for SOA Adoption’, http://www.itbusinessedge.com/item/?ci=15993, extracted from CIO.com, April 2006 Footnote 2 - http://www.microfocus.com/Resources/Whitepapers/binlink.asp?lststp=c&dlt=wp&id=&key=&cast=&fn=wp-ExtendingCOBOLtoSOA_tcm21-11529.pdf
|
