Building a Foundation for Service Oriented Architecture

The same can be said for IT systems in an enterprise. Excellent IT systems can be a competitive advantage, and it's difficult to purchase them out-of-the-box. Most successful organizations have great enterprise architecture to take them to the next level. Simply implementing a single integrated system won't necessarily meet the growing demand of a business. SOA can help you achieve your vision, and take you beyond what single vendors can offer. The question is how to solve the integration problem and bring all the discrete applications into a single homogeneous enterprise fabric.

WHY SOA MATTERS IN HEALTHCARE

Service-oriented architecture is not another piece of technology. It's a design methodology for systems and application integration. A deployed SOA-based architecture will provide a loosely integrated suite of services that can be used within multiple business domains. If you already design each business function and process as a pluggable modular system, then you are already doing some form of service orientation. A perfect service oriented organization will have variety of best of breed applications performing a core or granular service and using it to create a complex or simple service.

Although there are software tools available from vendors, such as ESB, BPM to SOA that can make things more automated, the reality is, service oriented business processes and architecture can be established without using any of these tools. Of course, a service bus and BPM will take your organization to the next level in SOA maturity. The advance of Web service technologies and SOA promises to have far-reaching effects on both internal and external applications. Web services using extensible markup language (XML), simple object access protocol (SOAP) and JavaScript Notation (JSON) allow applications to talk to each other seamlessly in a more native manner. Matured service design can lead to efficient automated business process management.

LAYING THE FOUNDATION FOR SOA

No organization can become service oriented overnight. It requires both careful planning and bringing discrete vendors together. In addition, your application integration team and architects play a vital role.

Vendors are extremely critical to the success of your SOA implementation. Once you have an architectural blueprint of SOA and a roadmap customized for your organization, you can start defining standards and asking vendors to comply with those standards. Eventually you will have a set of applications meeting those standards; and at this point, you may want to take advantage of the software tools available, such as ESB or BPM, to take the automation process to the next level.

Your application and integration team will come up with a list of services (some of them might be Web service). In a typical hospital, you may find some of the following services: admission; discharge; charges; room service; resource locator; orders; results; notification; and hand-off. The list can be long. The point is, all those methods done via HL-7 can be converted to services. Each of these services can be made up of more granular services.

The power of SOA is in reusing these granular services to create complex services and business processes. If you have unified communication in place, the architecture can extend to create communication enabled business processes. IT should consider agile and iterative processes for SOA where each iteration will produce a set of services-complex services would start building in later revisions.

While deploying Web service healthcare, organizations should invest a good portion of time in security architecture. Traditionally, security mechanisms are not very well suited for Web services, or sometime they can hinder usage of web services. Web services based on the XML, SOAP, and related open standards, and deployed in SOA, allow data and applications to interact without human intervention through dynamic and ad hoc connections.

Web services technology can be implemented in a wide variety of architectures, can co-exist with other technologies and software design approaches, and can be adopted in an evolutionary manner without requiring major transformations to legacy applications and databases.