October 10, 2005
SOA: Save Our Asses
One of my colleagues recently described Service-oriented Architecture (SOA) implementations very well: “It is about saving our asses”. As you would know from reading my blog and my academic papers, I am a big SOA enthusiast. The problem is that many public agencies see SOA as a silver bullet that will create interoperability, low cost integration of legacy systems and make them agile as never before.
SOA is no silver bullet. We need “traditional” business modelling and enterprise architecture (EA) in any SOA implementation. Here are a couple of SOA/EA basics that I recently send to a public agency:
- SOA ensures the functional integration of a single system (typically via web-services)
- EA defines the overall blueprint – interoperability across the enterprise (identifies the portfolio of available and needed services + SOA guidelines)
- No EA: technical anarchy and chaos
- No SOA: difficult to create interoperability across silos and legacy systems
- Successful IT-organizations blend SOA and EA (bottom-up and top-down)
Posted by khm at 04:52 AM | Comments (0) | TrackBack
September 15, 2005
The reality of SOA – based on Web Services
Jochen Schroll recently brought my attention to two very interesting articles from IEEE and HICSS about the performance of web services in a Service-Oriented Architecture (SOA). Today, we are all taking about the value of thinking service oriented. SOA is much than a traditional information systems development because it embraces business process modelling and enterprise architecture as well as object-oriented design and distributed systems. But, I believe that it is critical that we also pay attention to some of the technical challenges that comes with the value of using SOA as our pattern for designing distributed systems.
From a strategic business perspective, SOA is built around the notion that services map to business functions. Within computing, the term architecture can refer to lower levels of abstraction, such as a particular computer’s or family of computers’ internal architecture. But SOA generally refers to organizational IS architecture, meaning the unifying or coherent form being used to organize and design the construction, selection and interconnection of an organization’s hardware, software and communications assets. In this way, SOA is an architectural style for building loosely coupled distributed systems that deliver application functionality as services to be used for end-user applications.
Technically the ideas behind SOA build on SOC, a computing paradigm in which services are the fundamental elements for developing applications. In this paradigm ICT products are comprised of references to external components for the performance of various kinds of service. SOC can be used to wrap a service-oriented facade around closed-architecture legacy systems, thereby converting these to be compatible with more open architectures. A SOA framework can take advantage of these wrappers to enable more flexible and cost-effective integration of financial services that continue to use legacy systems, especially in distributed settings.
In many SOA implementations the promotion of well defined, published, and discoverable interfaces is based on web service technology. But what do we know about the performance when we use web services to integrate our IT-infrastructure? Well, according to the IEEE article XML parser, transport protocol, and the overhead of the new proxies in web services affect both the scalability and the latency of the reengineered application. As you might know from reading my blog, I am not a deep technical person. But, having read the two articles (and talked to colleagues about them) I strongly believe that we must consider these technical challenges very carefully before we engage in full blown SOA projects at the national, regional as well as local levels of government. Hopefully, my experiences here in DC with IBM and the federal agencies will shed some practical light on that…
Posted by khm at 02:13 AM | Comments (0) | TrackBack