Service-Oriented Architecture

by Rajat Bhatla

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.

Some of my key observations from the experience,

 

• As you might see from the outset, for someone unaccustomed to working with the IBM stack, it has a rather “elaborate” feel to it. At a high level it seems that modularity offered by providing layer-wise components is useful, but the associated complexity is a bit harder to digest.  IBM likely has a sound basis for configuring stack in this way. Possibly better suited to problems and projects of huge scale, where you can afford to dedicate teams to a particular application layer.  But, far more often development happens with small teams, and individual developers spanning the all layers of a development. Burdening then with 7 tools to manage their end to end isn’t a Project Manager’s productivity tip.
  

• The core Process server, ESB and App server is basically a Russian doll configuration of one tool built over the other.  But if you have to acquire BPM and ESB capability it seems that you have to buy each one separately.  Is it not possible for Websphere to be sold as a Core + Plugin configuration?  e.g.  1) Websphere standalone, 2) Websphere with ESB plug-in and 3) Websphere with ESB and Process Server plugins. Is it, that if it is done this way, clients will not need to buy all the three and then not need to buy some more hardware to stack them on top of each other? May be I am being too harsh, but my argument is that if I need a car with a sat-nav I don’t go a buy a new car; I buy a sat-nav. My feel of looking at the 3 products was that they all share a common framework and can possibly be bundled up as one.
  

In fact a question had been asked that Process server and ESB appear to be very similar products to the point of BPM looking like a rebadged version of ESB, so what is the distinction? One of the main answers was that Process Server should be used for Stateful orchestrations and ESB for stateless orchestrations. Well, is it then left to the user to define a distinction for himself while having paid extra licensing costs for each layer of the stack?

• Thirdly, is it not possible for business fabric, business monitor and business space functions to be woven into the business process server itself? Not just tool integration but inclusive in process server license as well.
  

Depending upon initial build requirements of a project one may may need a variable set of tools to start with from this list, chances are as requirements grow in complexity remaining ones will be needed as well.

In enterprise architecture, tools are enablers of implementation. When tools become too complex, the effort in adapting to the tools distracts from the core architecture itself and increases cost to business.

In meeting this premise better, I feel IBM  SOA stack needs to be configured or packaged in a way that makes it feel light, more integrated, easy to adapt to and cost effective.

 

 

Posted by Guest Author at 01:18 PM | Permalink | Comments (1) | TrackBacks (0)

by Murteza Salemi

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.
 

The organisation have a vision and key business drivers that when implemented through SOA it will require a consistent interpretation as it is put on the ground for development. Metrics and dashboards are tangible to business stakeholders to see their vision has translated to real effects.
 The actual development of SOA will take place step-by-step and project by project. Services that are developed in one and today’s project must satisfy future requirements and need, and today’s project must be able to leverage the services developed in yesterday’s project.

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.

Posted by Guest Author at 10:27 PM | Permalink | Comments (0) | TrackBacks (0)

By Anuj Sethi

 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.

IT Service Management (as defined by Wikipedia) is a ‘discipline of managing IT systems, philosophically centred on the customer's perspective of IT's contribution to the business’. So it’s a bit more than supporting client machines, servers, databases and network.
 
A key problem of 'Service Orientation' within IT (including the business part of IT) is bringing in is the explosion of terminology and acronyms. The main reasons of this are 1) vastness of this topic and 2) lack of standardisation.

Thus within the space of ITSM and now SOA Service Management there exist an endless list of new and existing terminologies which amplify the problem there by making it probably more complex than it actually is.
 
...'SOA Service Management', 'Runtime governance', 'Change time governance', 'Service Lifecycle Management', 'IT Service Management', 'ITIL', 'Production Support', 'Managed IT' , 'Infrastructure Management'....
 
I cover some points below which describe what is giving birth to this complexity/confusion in Service Management space with respect to SOA. Overall I believe some complexity is real, however some of it is perceived. It’s this way due to differences resulting from various viewpoints.
 
1) Understanding and Interpretation of the word 'Service' (in context of IT) is not consistent within and across the organisations. Thus at some point every IT organisation is required to define 'Service' in their context, one that gets well accepted within the organisation. Once this is done, the problem gets somewhat simplified.
 
2) Maturity of IT Service Management discipline. Although adoption of ITSM/ITIL disciplines is on the rise, not all organisation are in higher maturity state yet. It’s fair to state that an organization that has already employed an ITSM and ITIL implementation will have a much easier time defining and implementing runtime SOA governance and service management. Note the key benefit these frameworks provide is 'Governance' through policies and processes. This is building block for SOA service management.

To further complicate matters, nowadays there exist multiple frameworks to choose from and decide what & where to use and how they will work together. For e.g.: ITIL, COBIT, MOF, BS15000 ..etc
 
Well ITSM maturity posses the bigger question of overall maturity of IT Governance itself, but let’s not go digress there.
 
3) Proliferation of vendors in the IT estate. This one is quite obvious, if you have multiple vendors in the existing IT Management estate the complexity is probably already high. Every vendor has viewpoints on how their products are best used, thereby influencing the processes. Seamless integration and transparency are hurdles to cross in all dimensions of ITSM, i.e. Change Management, Release Management, Incident Management, Monitoring...etc.
Importantly we all are well aware that product vendors are always on the constant look out of means to sell new products, new versions of existing products. Thus new terminologies, acronyms are born as each vendor tries to differentiate and market the new shiny toys. (SOA momentum is helping them now than any time before.)
 
4) Operating model complexity. Another dimension of complexity is introduced due to the operating model of organisations. Typically a lot of IT Support / Infrastructure management is outsourced to multiple vendors under various contracts. Bringing these together into one way of operating/working is a gigantic task which goes beyond architecture/technology. Imagine, this would not be a problem if entire IT support across all architectural layers is outsourced to one single vendor.
 
5) Increased number of moving parts. I think this is sometimes exaggerated. "...very dynamic nature of SOA, many components, recombined for reuse.." Yes it’s true the number of parts will increase and their management will become critical. However if you look at existing IT service management, it deals with many moving parts even today. A critical application has at least following moving parts: middleware, web/application servers, runtime environments, database, operating systems, hardware, network etc.
 
6) Inconsistent understanding of SOA within the organisation. This is somewhat related to point#1, but with SOA adoption usually accompanied with concepts of Reusability - ‘lifecycle view of all assets’ and Agility – ‘iterative nature of processes’. This is quite a change from existing ways of working. Without adequate education and awareness within the overall IT organisation it’s difficult to pull people together towards the new way of working once it’s designed.
 
7) New architecture style so more complex management of running software. There exists a belief that SOA is new; so application/service management will be done completely differently and there will be huge impact on IT Support/Operate organisations.

I have a contrary opinion that existing IT Support organisation will find it easier to adopt SOA than the design/development organisation. Going back to Wikipedia definition of ITSM, IT support/management became ‘Service Oriented’ quite few years back and standardisation of same is on the rise. If anyone has had a look at ITIL v3, which is in existence for last 18 months, can appreciate this better. I will cover this more in my future blogs.
 
Lastly 8) Existing IT Architecture Maturity. If the existing IT application architecture state is making IT support/ITSM complex and inefficient, this will not improve by SOA adoption. Things will become more complex initially before reaching a managed state as the SOA adoption increases and standard processes are adopted.
 
In the next blog I plan to cover what are the best approaches to manage the complexity of service management in an end to end ‘Service Oriented’ environment.

Meanwhile, feel free agree or disagree with my thoughts and document your views about what adds complexity in this space.

Posted by Guest Author at 09:57 PM | Permalink | Comments (0) | TrackBacks (0)