SOA & Cloud

This architecture blueprint enters then a design phase where technologies and products are selected for each component and interconnection. The end result, the Design blueprint consists of detailed drawings of the interconnected applications components. The design is ready now for implementation and as such, at last, the architecture is implemented in a physical system out of interconnected applications.

SOA, a style of architecture, consists of recognisable and reproducible architecture patterns. The style is applied to a target architecture which, after the design phase, is implemented in a system. SOA is at the same time an integration technology for services rather than applications. This is what vendors try to sell you: ESB, registries... based on SOAP/XML, UDDI, WSDL etc. SOA technology integrates and interconnects rather than implements the services of a system. But vendors also offer, in addition, business process (and rules) engines, B2B systems, application servers, service management and other products in their SOA offer.

SOA, as a style or even technology, can be applied to a complex application design or to the target architecture of an Enterprise. The business component design of SOA is what people say you must do, not buy. You do have to specify your business services first and then interconnect them with a SOA technology. Can you say implement SOA services once you specified them? You probably can. And then integrate and orchestrate them with SOA and BPM technologies.

Now, you may find more answers in this book, the 2nd edition just published: "An Enterprise Architecture Development Framework" (subtitle "Business Case, Best Practices and Strategic Planning for the Enterprise"), available from Trafford at www.trafford.com/06-0421 and soon on Amazon.

Some of the content might be of interest to you although the book is not entirely aimed at IT people. The book describes an EA framework consisting of business, technology and people/organization architecture, EA frameworks classification and mapping, an EA development exercise to clarify the process and deliverables of the EA process at every step, the link between the Value Chain, business model, EA functional architecture and UML stakeholders' Use Cases, an EA maturity model, inhibitors and politics, relationship to SOA, BPM, ERP, Enterprise Architect role...

...

SOA adds a virtualisation layer by hiding the IT applications under business services. Since most applications will come with ESB capabilities, an Enterprise Service Bus (ESB) would standardise the communications to SOA services, hiding the network transport mechanisms.

At the EA business layer, processes and workflows would be implemented by process and rules engines as orchestration of SOA and Web Services listed and described in a catalogue (UDDI, WSDL). This abstracts away the complexity of IT and its applications under a layer which business people can understand. They can design and change processes using BPEL (Business Process Execution Language), as a composition of business services using graphical interfaces.

This is an important step forward in patching the divide between business and IT, since business people can, at least in theory, make abstraction of the IT infrastructure, issues, terminology... Business and IT will talk the language of business: services, QoS, SLAs, capacity, security, a vocabulary they understand. The business people can for the first time be in charge of the business processes. The business does not have to talk IT or understand IT any longer, and vice versa.

IT becomes a real business service provider negotiating service purchase, licenses, SLAs, very much like SaaS provider. An IT application suite would be seen as a set of business services now.

For the EA information layer, MDM (Master Data Management) adds a similar virtualisation layer since most application will utilise now information provided by this layer rather than supplied by all other applications. The MDM implementation may be integrated to SOA since the MDM hub becomes a SOA service for information access.

This will constitute a data abstraction layer for services and people using the information. Payback mechanisms should be put in place for this business IT interworking paradigm.

From a User Interface point of view, the fine Web2.0 interactivity further abstracts IT technology from business by providing a similar usability to client server applications but using web paradigms and as such independent of application implementation. An abstraction layer is introduced which consists of web servers understanding AJAX like technologies. Business users and customers, using Web2.0, will interact with these services remotely according to their authorisation.

Ultimately, the virtualisation of IT will provide technology services to business through a defined interface which would eliminate the nowadays tangled business-IT interaction

...

More often than not, agility and technology reuse are the major benefits associated to SOA. The reality is that SOA, frequently approached outside an Enterprise Architecture context, is developed incrementally, without the benefit of the big picture the Enterprise Architecture delivers. As a consequence, the promised agility is achieved late, towards the end of the SOAisation of your Enterprise when technology reuse may require costly redesign.

It is worth mentioning though that Business process reuse rather than IT is the advantage since SOA identifies similar business activities and groups them in a service. SOA reduces process replication followed eventually by the application de-duplication. Nonetheless, there are a few other major SOA benefits which should be more easily achieved, understood and accepted. Invoking these advantages would make SOA a joyous sell rather than the reported stressing experience.

1. Business service accountability, improving business and IT governance.

Applications and suites, usually a bundle of many functions, provide many services; in practice, a large group of business and IT people will share the responsibilities for the data and behavior of applications. But who can hold accountable such a group of individuals with many other responsibilities? Neither the stick nor the carrot would work in such an environment where neither accountability or authority can be assumed. On the other hand, for a SOA business service, there is a specific function or group assigned responsibility: it does not matter it is an IT or business issue, there is one single point of contact which will assume blame or the praise.

2. IT technology virtualisation behind SOA business services, reducing the Business and IT divide and enabling audit for a regulatory compliant architecture.

This a major achievement since your applications and technology are hidden behind IT services with contract interfaces supplied to the business. From a business perspective this is what really counts. IT becomes a service provider offering business services at a QoS secured by an SLA, well comprehended, quantified and eventually paid for by the business. No more blame culture. The separation of concerns pacifies the parties with no more business and IT divide as an additional advantage. The access is logged as well for various reasons such as regulatory.

3. Untangling the applications providing a clean architecture, reducing the side effects of change.

There is no more random access to parts of applications or databases which makes any change a burden and any modification of an application a major risk because of unforseeable effects.

4. Extended lifetime for your legacy applications, reducing the immediate pressure to replace them.

Although there are other increasing costs related to legacy technology, there is no more pressure to replace it; you can do it at your own convenience when a viable alternative exists. This is an extension of the technology virtualisation.

...

The relationship between SOA and BPM has been the subject of some debate recently. No wonder since in an Enterprise, there are different professional groups, magazines or activities to address them.

I would place them both in the Enterprise context, since SOA, for instance, may be applied, as well, to an application architecture. Then I would look into the conceptual and the technology sides of BPM and SOA.

BPM was in vogue in the 90ies as BPR, Business Process Reengineering. As a concept it is about discovering your processes, improving and automating them to reduce human error, delays and reduce costs. There are notations and languages to describe business processes. There are models that help evaluating the maturity of processes in a domain and frameworks, such as Six Sigma, for process improvement to reduce the percentage of errors in a manufacturing environment.

Business processes are also a part of the Business layer of the Enterprise Architecture (EA). The Enterprise processes would be described by a current and target process architecture described respectively by an As-Is and To-Be EA. Processes are still abstract in that they still have to be performed by humans and/or machines.

From a technology viewpoint, BPM is offered at the EA business layer, as Business Process and rules design, execution and monitoring engines.

SOA, on the other hand, is a business architectural style which might originate in the Object Oriented (OO) distributed technology and Web Services. But, the concept of service is not new at all, you can find it in the Yellow Pages. SOA, like the OO, is about providing data and processing, encapsulated and accessed only through a published interface. But, as opposed to OO, which addresses the SW development community, SOA aims at services business can understand and eventually orchestrate to implement end to end Enterprise processes.

In a SOA architecture, the business workflows will consist of orchestrated SOA services that encapsulate both process and the technology implementing it.

SOA is supposed to be implemented in the target architecture of an Enterprise; it does not exist in the current architecture. SOA, as a technology, is typically offered as an ESB (Enterprise Service Bus) product for services integration and UDDI/WSDL discovery and interface description catalogue. Web Services may be thought as a SOA implementation over the internet.

In a few words, SOA is a target style of BPM where processes are designed and implemented as a sequence of loosely coupled SOA services. SOA is an evolution of BPM aiming to hide, encapsulate complexity in business services. Business process engines are now offered as part of an overall SOA proposition, since they become SOA services orchestration engines working over an ESB.

...

Cloud computing is an overloaded term and vague at that. In short, I would define it as the outsourcing of your IT services - applications and technology - to 3rd parties over the Web.

Remote access only to these services may sound incomplete since it suggests interaction with people rather than applications integration, and leaving aside the outsourcing and subsequently the utility like service consumption that are the novel elements of the Cloud.

The Cloud is, in fact, a business concept even though created by the IT world. But so are SOA and Enterprise Architecture. And it should refer only to the services cloud of your Enterprise. Each and every firm may have its own cloud, that would overlap sometimes at multi tenant service providers. As a simple picture, it looks like an Enterprise Cloud of Services surrounding and serving your core company.

It consists of a few component service concepts (types of outsourcing services): SaaS, PaaS (XaaS)... (Application, Platform, Infrastructure, Security... as a Service).

PaaS (platform) and all its variants, part of the computing cloud, offer the opportunity to outsource not only your data center but platforms for your Web presence, content management...

Integration as a Service is an emerging service providing the orchestration and integration of the XaaS services.

The cloud covers both the IT application and technology layers of an Enterprise Architecture. Imagine, the EA Business Architecture layer resting on top of a fluffy Cloud of distributed, outsourced IT Application and Technology layers. The cloud symbol, coming from the networking world, signifies Internet distribution. Mind you, you still need to understand the overall Enterprise Architecture, but you need not bother with technology detail any longer.

Because of the mapping between various XaaS. a few business models are possible. At one end, your applications would be outsourced to different SaaS providers in the Cloud providing their own technology layer. At the other end, applications from various providers are housed by one or more Infrastructure/Data Centers providers, managed by 3rd parties.

Is the Cloud a technology? To start with, it is the business concept of outsourcing IT services, really.

As with SOA, companies such as Amazon, Google, Salesforce.com, Microsoft... provide various technological platforms/centers for you to use. If not relying on the Internet, I found them called private clouds. A number of these platforms may become part of your Enterprise cloud.

...

The relationship between SOA and BPM has been the subject of some debate recently. No wonder since in an Enterprise, there are different professional groups, magazines or activities to address them.

From a technology viewpoint, BPM is offered at the EA business layer, as Business Process and rules design, execution and monitoring engines.

In a SOA architecture, the business workflows will consist of orchestrated SOA services that encapsulate both process and the technology implementing it.

...

he good questions about SOA such as the relation to Enterprise Architecture (EA), is it architecture or integration and its success rate have recently re-emerged in dramatic public discussions. Here are a few articles - there are many more -:

SOA gets an obituary

SOA Versus Integration? Really

SOA is architecture with integration

With poor results, SOA disappointed the business people. Very true. It was said that SOA has died - this rushed away justifications since SOA pundits felt the sting - while its offsprings such as mashups, BPM, SaaS, cloud computing are alive and kicking. I would like to remark though that BPM, SaaS as ASP, and cloud computing as IT data center outsourcing, existed before SOA came to the fore. Mashups look more like "offsprings" but even they are an implementation of the existing Web Services technology. SOA had its contribution though in this spiral evolution.

Before making any judgment I would like to review what SOA is. It is a style of architecture based on services that can be flexibly orchestrated in end user processes. Integration is only implied here by orchestration. SOA can be applied to a software application or up to a full Enterprise as part of the target Enterprise Architecture. It depends on the scope of your endeavor.

The architecture side of Enterprise SOA, consisting of business services design and their orchestration in processes, would belong to the business people rather than IT. It is their job to "design" the business, if they need it. SOA is something that "you have to do" as pundits say. It is not really "you" in IT, but the business people.

SOA as architecture eases integration by providing modularization, encapsulation and "standard" interfaces for services. It does not specify the protocols or the technology choice though.

The integration implied in SOA belongs to the IT even though SOA is primarily about architecture. IT provides, in fact, all the technology - ESB, BPMS... - that facilitates services orchestration, integration, discovery, security, SLAs... This is the SOA you "buy".

SOA failed. The truth is that Enterprise wide SOA projects failed. The reason is simple: it was promoted, manned and driven by IT, solely. Business did not ask for it. It is the result of IT hype and push. It is not the job of IT to design the business.

The EA wide attempts at SOA fail for lack of support from Enterprise Architecture, business people and management.

In practice, had business been aware that SOA is about re-engineering the Enterprise operation, their reaction towards IT would be swift and lethal. In fact that lead to the SOA obituary.

From an IT viewpoint, SOA technology is an evolution of distributed components concepts and technology that continues to evolve, and as such, it does not really die. Being not necessarily SOA specific, the technology would survive the premature SOA fate.

The application (suite) SOA should be also well and alive. IT and software houses can engineer applications as software services e.g. SOA at IT applications or suite level, and integrate them with web services and ESB technologies. That is what happens in WOA, the side of SOA that IT can do. This is where SOA was successful, even driven solely by IT. SOA at application level is not dead and will not die soon. For instance,many ERPs are re-engineered now on SOA principles.

What would revive SOA at Enterprise level? Business people look more and more at the Virtual Enterprise, VE,(in business tongue also networked Enterprise, boundaryless company) even if they do not call it as such. The VE is made of partner companies cooperating to implement the processes in the value chain to deliver the products. Parts of a business, links in the value chain, are, in reality, outsourced to partners. This is where SOA needs to be incorporated into the bigger business context to provide the architectural framework for the VE. Cloud computing, SaaS, i.e. outsourcing IT to 3rd parties, become part of the Virtual Enterprise.

Enterprise SOA failed for lack of business support, drivers and proper preparation, given the project size and implications. The technology usually associated with SOA (ESB, BPMS, WS) for orchestration, discovery, integration is alive and well. Idem, SOA at the application and suite levels. Take for instance the trend to design applications suites observing SOA.

The Virtual Enterprise of the future, composed of orchestrated business services provided by partner companies will drive SOA along B2B to provide the agility and technology for interconnecting the networked Enterprise. IT needs to take a lead.

...

Business processes are linearly arranged in a sequence of cascaded activity steps. A business process is part of a single end to end (e2e) process or workflow. In contrast, an SOA service may be called by many e2e processes; it is designed and implemented once with reuse in mind. The SOA service:

* supports concurrent users calling from client processes

* provides the same access interface and messages (not necessarily the same version) to all users

* is designed for scalability to satisfy all potential customer demand

* delivers security and privacy of data and communication

* provides provisions for enforcing QoS for SLA agreements and KPIs for measuring the quality of delivery and usage

* supplies a management interface

* is managed on behalf of all users

* it often supports Web Services standards

* it is easily provided by an external supplier

What about Shared Services, are they a SOA type of development?

They are and they aren't. They are because they are reused by many Lines of Businesses (LoBs) in an Enterprise. They are not since they are mainly used by people rather than applications. Often shared services are performed by a mixture of humans and systems. SOA is mostly talked about in the IT domain although, in principle, it applies to people or/and technology services. Since Shared Services are frequently about Enterprise support services, they are often implemented in ERP technology. SOA in comparison, often applies to the whole Enterprise.

Shared Services are an important step towards SOA since the practice of sharing is already agreed upon. Shared services are SOA candidates. Once a SOA service is implemented, outsourcing becomes an option too since interfaces and SLA are already in place.

...

A definition of architecture states that it is the structure of a system and the description of its components and interconnections. As a structure, the architecture exists in any system, no matter how convoluted; and it can be described by an architecture diagram. For the target state of a system, a blueprint is drawn to describe the desired logical architecture of the system, that is its components and interconnections. This architecture blueprint enters then a design phase where technologies and products are selected for each component and interconnection. The end result, the design blueprint, consists of detailed drawings of the interconnected components of the systems.

The design is ready now for implementation and as such, at last, the architecture is implemented in a physical system out of the interconnected products. A style of architecture consists of recognisable and reproducible architecture patterns. SOA is a style of architecture applied to a target system. SOA, as a style, can be equally used in an application or in the target architecture of an Enterprise. SOA architecture, after the design phase, is implemented by the systems delivering the SOA business services.

SOA is at the same time an integration technology for services rather than applications. This is what vendors try to sell you: ESB, registries... based on SOAP/XML, UDDI, WSDL etc. SOA technology integrates and interconnects rather than implements the services of a system. Vendors also offer, in addition, business process (and rules) engines, B2B systems, application servers, service management and other products in their SOA offer.

The SOA business services design and orchestration is what people say you must do, not buy. You do have to specify your business services first and then interconnect them with a SOA technology. Can you say implement SOA services once you specified them? You can. But you can equally say that you buy SOA technology to integrate the systems delivering the business services.

...