Getting a Handle on SOA How to Kick-start your SOA Initiative in a Fortnight

Transcription

1 Getting a Handle on SOA How to Kick-start your SOA Initiative in a Fortnight 1 (13)

2 Table of Contents Introduction... 3 A Brief History of Service Integration... 3 Point-to-Point Spaghetti... 4 Hub and Spoke... 4 Enterprise Service Bus (ESB)... 5 Business Process Management (BPM)... 6 Governance... 6 SOA Security... 7 The Baseline Methodology... 7 Concept Model... 8 Documents and Templates... 9 Roles and Organization... 9 Zystems and the Baseline Start kits The Baseline File Transfer Start kit The Baseline ESB Start kit The Baseline DataPower Start kit The Baseline BPM Start kit The Baseline WSRR Start kit The Baseline Integration Center Start kit Beyond the Start kits Business Strategy Governance IT and technology Summary For more information (13)

3 Introduction Companies today face an increasing rate of change, which puts severe pressure on business leaders to quickly adapt to new market demands. Since IT is so thoroughly embedded in the execution of most business processes, the demand for highly adaptive IT systems is likewise increasing. But how do you achieve this adaptability? The last couple of years, SOA (Service Oriented Architecture) has been touted as the solution to this problem, yet many find it hard to know how to get started with SOA. This white paper describes some of the areas you need to address in order to build a sound technical SOA foundation. To be sure, SOA is about a lot more than technology (organization for instance, as explained toward the end of this white paper), but many IT departments find themselves grappling with practical, down-to-earth ways of securing the technical aspects of an SOA. If you re working in one of those departments, this white paper is for you. And if you re new to SOA, this white paper will hopefully help you understand what SOA is all about and why it is important. A Brief History of Service Integration At the core of SOA lies the idea of a Service. A Service is basically a piece of business functionality, exposed in a way that allows systems and people to access the Service using open standards (such as HTTP and XML). This allows for interoperability over different platforms and provides a way of grouping logical business functionality in a way that enables applications to be assembled in much the same way that you can quickly build and re-build stuff with Lego bricks (each brick being a Service). The underlying rationale for SOA is flexibility, so that new business demands can be quickly realized in the IT infrastructure. There has been a number of steps on the road to SOA (and increased flexibility), the most important of which are briefly described below. 3 (13)

4 Point-to-Point Spaghetti In pre-soa days, systems integration was typically conducted in an ad-hoc manner, leading to poorly documented IT eco systems that quickly became very expensive and hard to manage. In the 90 s, a new breed of middleware products entered the market, designed to tackle this problem. Hub and Spoke This architecture attempts to resolve the spaghetti issue by introducing a piece of middleware that deals with some recurring integration functionality requirements, such as routing, data transformation and protocol conversion. EAI (Enterprise Application Integration) emerged as a new discipline, drawing heavily on the features typically provided by this new middleware. The middleware in itself only partly alleviated the issues of rigid IT systems. Granted, doing EAI in a disciplined and well organized manner (by using methodologies like Baseline from Zystems) greatly diminished some of the more pressing problems of the old spaghetti syndrome, such as unmanageable IT eco systems. It did not, however, enable the flexible reconfiguring of IT assets that the new era required. The main problem was that the middleware and accompanying methodologies did nothing to promote standardized interfaces to the functionality embedded in the participating systems. It is at this point in our story that the Service concept comes to the rescue. 4 (13)

5 Enterprise Service Bus (ESB) So, how do you go about exposing business functionality as a Service? Well, open standards are at the core of this question. The whole idea of a Service is that it should be accessible to the widest possible range of applications, running on all sorts of platforms. Using open standards will go a long way toward achieving this goal. To many people, Web Services provided the standard for this. Two things are important to point out here, however. First, a Web Service is not automatically a SOA style Service. Second, a SOA style Service is not necessarily a Web Service. Especially if you re looking to build a service portfolio for internal use only, you re free to stipulate pretty much any standard way of exposing a Service you want. Now, in the best of worlds, all applications are natively able to participate in exposing and consuming Services using whatever standard way you ve decided to use (e.g. Web Services in the form of SOAP over HTTP). But guess what? We re in the real world, infested with a plethora of legacy applications, stubbornly resisting any attempts to shoehorn them into the WS world. Enter the ESB. The job of the ESB is to help those faithful old servants to participate in the exchange of Services. As the picture suggests, applications hook up to the ESB, and the ESB do whatever magic is needed to expose the application s functionality as a standardized Service (the little lollipops sticking out of the top of the bus). So now we re suddenly equipped with a set of Services that are invoked using identical technology. What next? 5 (13)

6 Business Process Management (BPM) To gain the full benefit of those nifty Lego bricks (the Services), we want to have a uniform way of assembling them into useful applications, ideally reflecting the business processes that they are part of. A new class of software to model and execute those processes has emerged, along with a new discipline: BPM. The ultimate aim of BPM is to be able to model business activities together with the people who know the business, take those models and generate automated processes, then execute those processes in a process engine, invoking reusable Services as needed. In its most advanced incarnation, BPM will also include the ability to define various metrics reflecting things like process efficiency and cost. Those metrics (or Key Performance Indicators, KPI:s) can be used to simulate the modeled process in order to improve it. They can also be automatically harvested from the running process to monitor, in real time, the health and performance of the business. Governance In order to achieve all the benefits of SOA, the design and implementation of both Services and Processes must be subject to strict policy alignment. One of the key features of an SOA style Service is that it should be reusable, i.e. it should be able to participate in a greater context as an autonomous, self-contained unit. We have already mentioned the importance of standards to achieve this. In order to ensure that development of new Services is done in accordance to those standards, Service design and implementation must be monitored by some organizational body that has the overall responsibility to ensure standards compliance. Another vital aspect of this work is that a Service, in order to be reused, can be easily located when a new development project needs that particular piece of functionality. To maintain this dictionary (or registry) of Services is also the responsibility of the Governance organization. Not surprisingly, another breed of software products has emerged to address Governance issues. They typically have names with words like Service, Registry or Repository in them. They will help out with things like Service Lifecycle Management (who can do what to a Service when?), Service Registry (what Services are available for my use?) and Dynamic Endpoint Lookup (which Service should be called in this particular instance of a process?). 6 (13)

7 SOA Security Two aspects of SOA converge to drive new requirements for security and performance. First, most SOA s will rely heavily on large amounts of XML being shuffled around, a lot of it over HTTP. Second, one of the core aims of SOA is to be open, to make available IT assets to a wide range of users, both internal and external to the enterprise. Lots of users, massive amounts of XML and HTTP transport (which sneaks through most firewalls) will all combine to put heavy demands on using encryption, validation, authentication and authorization. Especially XML processing (such as encryption/decryption and validation) is extremely process expensive. So much so that many companies will forfeit security in order to gain performance. The solution to this is to use dedicated hardware and software to address these issues. XML appliances (i.e. dedicated hardware boxes) are available to offload XML processing from application servers and ESB s. The Baseline Methodology After having completed a number of SOA projects, you come to the not-sostartling conclusion that a lot of the stuff you do is done in pretty much the same way regardless of the systems involved. You design and implement services. You connect the ESB to various systems by invoking Web Services, or reading and writing records to database tables. You document your work. You deploy similar artifacts in similar ways to the same environments (e.g. test environment and production environment). A sound methodology should capture those general components and make them available to all people involved in SOA projects. Examples of such components include reusable software, document templates, procedures, and roles. If you think you ve seen this before, you may well be right. RUP (Rational Unified Process) is an example of such a methodology. RUP, however, is an allpurpose software engineering discipline, not immediately applicable to SOA (or any other specific software engineering endeavor, for that matter). What we will focus on in this white paper are the specific features of an SOA development methodology. 7 (13)

8 Baseline (developed and marketed by Zystems by Enfo) is a methodology that distills tens of thousands of hours spent integrating IT systems of some of the largest enterprises in Scandinavia into a lean packaged Best Practice for implementing an SOA. The picture below illustrates the components of the Baseline methodology. Concept Model A sound SOA will have a coherent design that permeates all solutions deployed on it. In order to achieve this coherency, Baseline defines a small number of key objects and their relationships to each other. Every solution will be modeled using those objects. All document templates are structured using the same objects. Integration work generates a myriad of artifacts, such as documents, source code files, script files, binaries, and so on. Naming these artifacts in a consistent way is no small feat (as anyone involved in designing naming conventions will testify). Structured around the concept model, Baseline includes a comprehensive set of Naming Conventions, ranging from the naming of documents, all the way through the naming of source code files, and how to structure and name folders in a versioning system. An example of such an object is the Contract. The Contract explicitly defines the relationship between the Consumer (another object in the Concept Model) of a Service and the Service itself. 8 (13)

9 Documents and Templates Documenting an SOA in a consistent way is crucial for achieving a number of important goals: Maintainability. Supervising and managing an SOA is a complex art, since it will involve a number of operating systems, servers, software components, and contacts with system owners. Having a set of consistently designed documents, all kept in the same place, describing all solutions deployed in the SOA is absolutely essential for this task. Reusability. One of the key promises of SOA is the concept of reusable services. However, a service poorly documented, and hidden away on some shared disk in a network, is not likely to be identified by new SOA projects on the lookout for reusable services. Having all services documented in a consistent manner in a central registry is a minimum requirement for service reuse to happen. Quality. Working with design and implementation supported by document templates ensures that all relevant questions are asked at an early stage (providing the creation of the documents is a living part of the design and implementation process rather than an afterthought). Baseline provides a comprehensive set of templates and documents covering all aspects of an SOA project, including: Requirements collection Project startup Solution design and implementation Testing Packaging and deploying solutions Maintaining solutions in a production environment Governance Roles and Organization Defining a number of roles, and delineate their responsibilities, is a crucial part of any successful software development effort. Baseline defines a detailed process for producing deployable solution packages, and identifies a number of roles. Having clear demarcation lines between the roles ensures a concept know as Separation of Duties. As an example, the project team involved in producing a solution package is never allowed access to either QA (acceptance test) or production environments. This means that the people responsible for producing the code are physically 9 (13)

10 unable to put it into production. Instead, a well defined process of handing the solution package over to the operations staff is defined in Baseline. After verifying the completeness and quality of the package, operations personnel are then responsible for deploying it. Zystems and the Baseline Start kits Zystems has been dedicated to delivering high quality integration solutions based on IBM products since we started in From the outset, we have wanted to make it easy for our customers to get started. Over the years we have developed the Baseline Start kit concept to enable our customers to kick-start their SOA journey. The Baseline Start kit is a set of activities offered at a fixed price aimed at introducing and implementing IBM software and well-tried best practices in an organization within 2-6 weeks. It includes: Architecting and installing relevant IBM WebSphere products Training of the customer s staff in using the WebSphere products (as well as Baseline Methodology and Software components) Completing a simple first project, using the Baseline methodology and deploying the solution on the installed products The Baseline deliverables themselves (Best Practices, Document Templates and Software Components) Using the Baseline Start kit, numerous organizations have successfully launched their SOA initiatives. Today, we offer six start kits. The Baseline File Transfer Start kit This start kit will help organizations that struggle with rampant file transfer chaos get a grip with the help of WebSphere MQ File Transfer Edition (MQFTE). MQFTE will add stability and security to all transports and centralized configuration and traffic logging, as well as being the first stepping stone towards ESB and SOA. The Baseline ESB Start kit This is the original start kit. We have been delivering the ESB start kit since the very beginning of our existence. It will get customers started with WebSphere Message Broker or WebSphere ESB. 10 (13)

11 The Baseline DataPower Start kit This start kit focuses on SOA Security as provided by WebSphere DataPower SOA Appliances. The Baseline BPM Start kit This start kit introduces WebSphere Modeler (to model business processes) and WebSphere Process Server (IBM s business process engine). The Baseline WSRR Start kit This start kit helps customers launching the WebSphere Service Registry and Repository product (WSRR) to address Governance issues. The Baseline Integration Center Start kit This start kit, finally, helps customers set up the roles, processes and organization required to conduct efficient SOA development work. It is different from the other four start kits in that it does not focus on any specific IBM product. It is completely soft, i.e. it only concerns itself with supplying best practices around SOA organization. Beyond the Start kits The start kits aim at providing our customer with a solid technical foundation for SOA. However, to realize SOA fully, both IT and management must join forces. Management must actively work with IT, viewing it as a strategic asset that can enhance the enterprise s competitive edge and not as a burdensome cost driver. To successfully deliver SOA, the enterprise must simultaneously address three organizational levels: 11 (13)

12 Business Strategy On this level, management has fully realized the strategic importance of SOA to enable the business to deliver on constantly changing market demands: new trends, new competitors, new business models, new markets etc. Management is actively engaged in ensuring that the business s processes are modeled, analyzed, simulated and tuned, and that they are realized using well designed SOA style Services. From the management s perspective, this means that it is considered a strategic priority to invest in business analysis and governance. The very real and thorny issues of how to fund the development of shared resources (such as reusable Services or processes spanning traditional enterprise silo boundaries) are squarely addressed, because it is understood that the only level on which these questions can be realistically handled is on the strategic level. Governance On this level, expertise in the areas of business modeling, process automation and Service design is provided. Care is taken to ensure that all SOA solutions adhere to well defined policies. The concepts of integration and SOA are constantly promoted within the organization. Zystems has helped some of Sweden s largest corporations set up and operate their Governance bodies. We do this by offering the Baseline Integration Center, a process framework for Governance based on Baseline Best Practices. IT and technology On this level, solutions are realized in the IT infrastructure. Here, Zystems provide start kits, development projects and solution maintenance for all the IBM products mentioned in this white paper. 12 (13)

13 Summary This white paper has presented a brief introduction to SOA, and what technical and other aspects you need to address in order to establish a sound foundation for your SOA, the most important of which are: The ESB that enables legacy applications to participate in an SOA and expose their functionality as standards based, reusable Services Business Process Modeling and Automation that enables flexible assembly and reassembly of Services to meet quickly changing business needs Governance that ensures that standards are met and that Services are made available for all potential users Security We introduced the Baseline Methodology and the Baseline start kits (ESB, BPM, SOA Governance and SOA Security) that help you address each of the above aspects in turn. Finally, we concluded that as important as these aspects are, the full potential of SOA will not be realized if not the entire organization, from management downward, is engaged in the realization of SOA as a strategic necessity for any business that lives in an ever-changing world and relies on IT for its survival. For more information If you want to learn more about Baseline and Zystems by Enfo, visit our web-site at 13 (13)