So that’s all I have. It is very difficult for me to anticipate what will be going in the people’s head when they read this blog (so risk is entirely mine) but if you have your wish-list for Santa for SOA for 2010 and beyond then treat this blog space as your home and share with us what your wishes are. Who knows, Santa just might be listening to all this and it could turn out to be a rather serious affair. Wish all of you a great X-mas ahead!

I had attended a workshop on understanding IBM SOA technologies at IBM South Bank London a few months ago.  At the time I was also on a project where we were defining an enterprise SOA based landscape.  So it was quite a good timing with live practical experience on one side and IBM on the other. It proved a rich learning experience, combined with interactions with SOA practitioners from different streams, hands on labs and highly experienced IBM staff. In this post I’ll just focus on the Websphere stack of tools that we were exposed to, and my takeaway feelings about the set of products that we did hands on with.

More or less accurately, the IBM SOA stack comprises of the following,
Stack comprises of

• Rational Application Developer
• Integration developer (Eclipse)
• Service Registry and Repository
• Process Server
• Business Process Fabric
• Business Monitor
• Business Space
• ESB
• Business Rule engine (inbuilt)
• Business Integration Server

There was a guiding case study that took us through implementation aspects of each of these tools in building an SOA enabled enterprise stack.  There was little coding, mostly configuration around these tools. It was a 3 day workshop, but even then with the number of tools to go through quite packed.

Reflecting on my recent engagement within educational sector I touched and felt the SOA architectural challenges again. Going to the workshops to understand the requirements and business processes it was quite evident that the challenges for an SOA architect do not stop with solving only the technical sides of the SOA architecture. The architect must also coordinate and guide the enterprise’s collaboration between business processes, people, information, and technology to ensure the focus remains on achieving enterprise’s goals rather than anything else.
 

Services present the capabilities and the structure of business processes, applications, systems, etc. One typical challenge faced in an organisation is that business processes are intertwined with legacy systems and applications and the obvious consequence of this tight coupling is that it is no longer possible to design one without changing the other. Thus, building SOA architecture must not be considered as purely technical exercise but it is also a business exercise that requires the active participation of key business stakeholders. The immediate impact of business involvement is validation and verification of business services required for development.

Building SOA architecture is a long term journey and should not interrupt the core business functionalities from delivering value and making revenues. SOA will not be built from scratch but it will be depending upon a set of processes and legacy systems. In practice this means that existing business processes and systems will evolve gradually into an SOA and changes are introduced incrementally and rigorously.

 I would like to begin by stating that the title above can be interpreted in multiple ways (yes it’s the word ‘Service’). Hopefully by the end of this blog you will be able to appreciate why I have stated so.
 
In most organisations the IT part has two sub-organisations: One responsible for design/develops the software (equivalent of a car manufacturing plant, at some level) and another which actually support the running software (equivalent of a car service station). The focus of this blog is on the latter.

Service design considerations for Cloud
In the first part I talked about how SOA and cloud computing converge. SOA does give us the ability to move around services to the cloud. However it might not be sufficient to design services the traditional way. Cloud brings with it a whole new way of doing things. Cloud enabled services should have the following consideration:
 

•  Cost implication: A cost benefit analysis is a must before the services are moved to a cloud. Cloud vendors typically charge for bandwidth usage, execution time and storage cost. As such it is important that the service designers and developers keep that in mind. Resources should be sparingly used and released at the earliest possible opportunity. Data transfer between consumers and clouds should be properly analyzed. For ex: If the service needs huge volume of input and output data it might not be a good candidate for Cloud. The overall cost of hosting such a service in the cloud may actually exceed than that of in-house maintenance.

• Design for failure: Cloud platforms are built to handle failures. However there could be downtime and network issues. The application should be designed and deployed in such a way that a failure in the cloud service doesn’t impact mission critical application. For ex: customers of an e-commerce application should be able to shop even though the disks are failing and data centers are down. Amazon’s Dynamo is one such platform which provides such reliability.

• Avoid Vendor lockdown: This is more relevant to the SaaS and PaaS model. Ideally the consumers should be able to move from one cloud provider to another without hassle and avoid any sort of vendor lockdown. This seems a little far-fetched at this point of time. Efforts are on to form an open standard for the Cloud. The opencloudmanifesto is a step in that direction. The Open group has also got into the act of providing an open standard.

• Regulations and laws: In certain cases it might be mandatory as to where the data can be hosted. Some laws like SOX and HIPPA might prohibit enterprise to move certain category of data out of their premises. Services should take these into account.

 Conclusion
Cloud computing is revolutionary in nature. The benefits are too compelling to ignore. As the cloud space heats up, it is important to align your organization properly.  Organizations who have implemented SOA will find it easy to move to a cloud environment. Such applications are not limited by the existing hardware and software. However sufficient due-diligence needs to be done before embarking on a full-fledged cloud exercise.

Within SOA space we have seen many definitions for what exactly SOA is, what problem it can solve and how. These varied and diversified definitions have been the main source for the confusion among both the business users and technical architects on what SOA is and how it can help. A group of smart experts and practitioners have acknowledged this issue and came together during 2009 to develop the SOA manifesto. The SOA manifesto consists of a set of core values and principles that can guide the SOA initiatives and programs on their SOA journey to make sure they do not go astray and keep them on the right path.

• Business value over technical strategy
• Strategic goals over project-specific benefits
• Intrinsic interoperability over custom integration
• Shared services over specific-purpose implementations
• Flexibility over optimization
• Evolutionary refinement over pursuit of initial perfection

Following are some of the guiding principles:

• Respect the social and power structure of the organization.
• Recognize that SOA ultimately demands change on many levels.
• The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries.
• Products and standards alone will neither give you SOA nor apply the Service orientation paradigm for you.
• SOA can be realized through a variety of technologies and standards.
• Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards.
• Pursue uniformity on the outside while allowing diversity on the inside.
• Identify services through collaboration with business and technology stakeholders.

For a complete list of the principles refer to the SOA manifesto.

• Starting too big and starting at the wrong place/time. Before beginning the SOA journey, one needs to ensure that the right initiative is identified to manage the expectation of SOA outcome. For example, achieving SOA as part of a high profile time critical business transformation program would be the wrong place. Another situation could be trying to do SOA as part of a program which is already late in the solution delivery process.
• Isolated technology focus (e.g. Buying the full range of SOA products right at the beginning of SOA journey even though all those are not required at the beginning and without the processes and governance in place)
• Isolated architecture focus (e.g. Focus only on the integration layer/business services, No focus on infrastructure services)
• No formal central governance/competency group (CoE or centralize SOA team) and ownership of services. This creates scenarios like ‘unregulated’ development of services without checking reusability leading to redundancy and duplication of services (violates the core principles of SOA)
• Not adapting (or enabling) the operations and support model to support/leverage SOA (Impact on service management areas: Incident Management, Release Management, Configuration Management etc)
• No systematic Service strategy (Service planning) and design e.g. Service design without proper business modeling
• Strategy to measure the value of SOA and report to the stakeholders is absolute must. Not having a plan to measure would be disaster as the value of the SOA may not be clearly visible without the right data (number of time reused, reduced development time, faster response to business etc.) handy
• Making SOA high visibility and demand sponsorship without demonstrating the value (creating a business case for SOA is always a challenge). Ideal approach sometimes is to do mix of bottom-up and top-down. SOA can be introduced in "stealth" mode (for the business) without creating too much distraction.
• Not articulating the business value/impact of SOA (direct tangible links to business objectives) and presenting it purely for architectural purity. This limits the business sponsorship and funding

 

And at the end ‘Governance’ is KEY to successful SOA. Through an on-going governance process, organisations need to measure how far one is from the SOA goals and what is going good or bad. Having right governance in place, all or most critical pitfalls of SOA could be addressed. Lets define the SOA governance and make it work – you are all set for SOA! 

Simplistically put, Cloud is about Hardware and Software outsourcing. You don’t care about managing and procuring either of the two. If dissected properly Cloud is a bunch of services delivered over the internet or extranet. Everything from Infrastructure (IaaS) to Platform (PaaS) to Software (SaaS) is exposed as discrete services. Though the concept has been there for quite some time, the current technology advancement in virtualization, grid computing and network reliability has made it a reality.

‘SOA Security’– How much is enough? – Good question, but meaningless without the context. It is a must to spend a while researching exiting security architecture to comprehend the context. In majority of the cases, the organization probably already has a pretty robust security system(s). The challenge with SOA is to figure out how to extend those existing security measures to those services that comprise SOA. Many SOA security solutions are designed to interconnect effectively with existing security functionality. At that point, the security risks might begin to look a bit more manageable and you can proceed with your plans.

Coming up with service categories seems at first an easy task but when you start thinking about it and discuss it with other architects, you will be dazzled on how many different definitions exist out there. It is not a matter of which one is right and which one is wrong but how we are going to agree on one set of definitions and terminology so we can talk with each other and using the same words (terminology) without having different meaning (unambiguous) for them.

There are quite a few in the list. Here are some examples of service categories:

• Business Services
• Capability Services
• Activity Services
• Information Services/Data Services
• Entity Services
• Application Services
• Presentation Services
• Composite Services
• Technical / Infrastructure Services
• Technology Services
• Utility Services
• Communication Services
• Integration Services
• Bus Services
• Process Services
• Master data services

 

Remember – you have to get this fixed right at the beginning of the SOA journey. It looks very trivial things but not having the right set of category defined will have long lasting negative impact and creates confusion within the architecture and business community.

Lets go and finalise the Service Category if you have not done so.

There was an interesting discussion on User experience being at core of the final rendering of a service, and how the interactions between consumers, producers is core to the notion of "value". No doubt this is an important area of research from the perspective of justifying investments in IT, in current circumstances.

This was followed by thought provoking presentations including papers on BPM adoption, and software engineering issues related to BPM and SOA, including two innovative papers from Infosys titled "A holistic approach in context of Enterprise BPM adoption" and  

"Challenges and Approaches during requirement gathering phase for multi release BPM engagement" respectively.

More soon.

by Murteza Salemi

The fundamental rethink approach required for implementing SOA initiative in an enterprise is that SOA program should be driven by business (business driven SOA) and not technology or vendor products. Furthermore, the initiative must target specific goals and offer ways of objectives measurement.

Identify key stakeholders and communicate the business benefits gained by running SOA initiative, making sure to be clear and specific about each goal achieved by SOA and how it can be measured. Furthermore help these stakeholders to understand the value gained by a project using a Services Model’ as the paradigm of the future, without resorting to discussing vendor products and technology platforms.

Once the to-be state of the business processes are identified and communicated across the enterprise and tied to the business benefits of that enterprise, SOA initiative will have solid ground to start its detail work.

Be prepared and make preparations for a multi-year change journey - SOA is not a tactical fix, or integration solution it is the opportunity for successful business change.

REST has made huge inroads into the Services space in last few years. It has become a very popular style to define how the Service Interfaces are designed and how the Services are accessed. Since SOA is also all about "Services", it is obvious that there will be an inclination to draw some correlation between REST and SOA and rightfully so. Sometimes that does open doors for some confusion and you start asking questions like “Am I not implementing SOA if I adopt REST style?” or “Does REST have inherent support for SOA?” or “Is REST the next level to attain after SOA” or even “Has SOA given way for REST?” and so on. So it does make sense to try to understand these two concepts and try to correlate the two.

• Standardized Service Contracts
• Service Loose Coupling
• Service Abstraction
• Service Reusability
• Service Autonomy
• Service Statelessness
• Service Discoverability
• Service Composability

 REST – Representational State Transfer – is an architectural style. The basis of the REST style is that you define the resources for your application and then use the standard HTTP methods to perform the state changes to those resources. Some key features of the REST style are –

• Unique identifiability of the resources through URIs
• Uniform interface to access the resources
  
• Navigability of the resource representations through hypermedia
  
• Statelessness
  

 Now if we see at the key features of the REST style, each one of them does map to one or more SOA principles. For example, “uniform interface to access the resources” maps to standardized Service Contracts, Service Loose Coupling and Service Abstraction. Except for one SOA principle – Service Discoverability – that is not directly covered by the REST features, all other basic SOA principles are realized by one or more REST features.

So now let us try to correlate the two. As defined in Wikipedia, REST is "a style of software architecture for distributed hypermedia systems such as the World Wide Web". Also we have already seen that the features of REST are very much compatible with the basic SOA principles. So we can draw the correlation that REST is an architectural style that inherently helps to attain some of the basic SOA principles and this is even more a perfect match when you are designing SOA under the constraints of "distributed hypermedia systems”.

To optimise your SOA benefits take the next step and virtualize. Virtualization is the abstraction of hardware/infrastructure resources (network, disk, memory, etc.).

Virtualize your SOA solution when you want to further:

• Reduce capital expenditure on hardware and infrastructure
• Reduce operation expenditure and the number of staff required to operate the enterprise applications.
• Go green and reduce power reduction

Don’t virtualize your SOA solution when:

• Requiring high performance (high bandwidth) if the virtual environment not capable of matching the SLA for performance
• Small number of concurrent users or local limited usage of application
• Requirements for editing capabilities over the WEB
• Intensive disk I/O operations, such as dynamic mapping and map caching which perform faster on physical machines than on virtual machines.
• Some CPU-intensive applications might negatively be affected if the virtual environment capabilities are limited.