Service-Oriented Architecture

5 Questions for IT Organizations to worry about

2010-03-11T08:57:24Z

Changes are taking shape. Some are evident, many are like undercurrents, yet not prominently visible but slowly moving the needle, like global warming. I'm talking about the changes in the industry with respect to future of IT and IT organizations. Where businesses stand today and what they need in future, how much ready are IT organizations to make it happen for them?

]]> While today we mostly ask the questions in terms of new technologies as far as the IT organizations are concerned for their readiness, I think its going to be far more fundamental that we will need to worry about going forward since the changes happening around will make many of the existing models, methods and patterns of IT services irrelevant. Lot of this has to be do with the changing expectations of how IT will be used in future, how products and technologies in IT are going to be like and how businesses are going to structure themselves to make business happen on IT driven business operation eco-system. Needless to say, that this eco-system is not just applications but digital devices, sensors and all that you can think of. In recent past I had quite diverse conversations with organization leadership teams, especially in the context of Business value strategy. Using that as a background and seeing what else is happening around, here is what I think should be top 5 worry for the IT organizations that are providing services to their business owners.

What is the cost that your organization is paying for your constraints? - constraints could be your service levels in terms of response time, could be quality, could be ability to resolve business challenges. Most important thing is that you as IT organization, are you aware of cost that business pays for every constraint that you bring on the table? You may not be watching but trust me, one who is paying the cheque for your services is watching it. Check it out.
Given a chance of better ‘service provider’ today, will Business owners replace you? - Don't get surprised. Many organizations treat their internal IT organization as yet another IT services provides and pretty much deal with them like one. Organizations have kind of got into mindset of looking for better options if their internal IT organization is not able to perform upto the mark. Options are always there, its just matter of making the decision. Its all going to be 'business value' game and every one will have to earn the cheque through business value delivery and not just by 'doing things'. Serious stuff, I think.
Will you remain relevant ‘tomorrow’ with changing patterns of technology evolution? - Changes are happening rapidly and some of them will change the game for businesses. Linking back to previous point, you as service organization, how much are you ready to enable your businesses to leverage the new technologies without reading putting much to stake in terms of risk? If you do not evolve, new technologies will make you irrelevant in terms of your servicing capabilities and point# 2 will make it even more serious.
Are you busy solving your internal problems or are you solving business problems? - Watch out where are the leaders and managers of your IT organizations spending their time on. If they are busy sorting out their internal issues and not really providing leadership in resolving business challenges through IT capabilities, there is lot of wastage happening. Its not more affordable.
How much can your business organization rely on you for their future bets? - Probably THE most crucial question that IT organizations need to think of. Can their businesses rely on them to capably provide support for the future business bets of the organization? Businesses are in transition and hence no one really knows how things are going to be turned out in future. But they are picking up their best bets and playing on it. If IT organizations are not able to support the future bets, that's lot to lose, big stake. So first, as IT organization, are you aware what those big business bets are for your organization and secondly, are you ready to make those bets happen from your end?

Is this scary? It should be. But again, its meant to show the good news also. While it is scary, it also means that current way of doing is not going to sustain so you have option to change the game. That's exciting part of it. You get to be part of the change and not just being part of the change but leading the change. Can you ask for more?

“Information as service” is a strategic enterprise level initiative in service orientation journey

2010-02-27T14:05:58Z

By Murteza Salemi

Information in SOA world is often considered only within the context of specific services and processes whilst the most awaited gains and benefits of SOA investment is business information availability throughout the organization and to its partners and regulators. When an organization embarks on SOA and integrates its internal systems across LOB’s it will soon discover that there are inconsistencies in its information that was not visible before as it was hidden within various silo applications and data sources.

]]> SOA focuses mainly on mapping service components to business processes, and on mapping business processes to business services. However, during this process the quality of the data involved is either ignored or given low priority. Implementing and running services on top of distinct legacy systems, applications and repositories, each with their own levels of data quality and without cross-system de-duplication and cleansing, results to an SOA solution that looks great on the surface but internally hold poor data quality. How can one, for instance, implement an enterprise wide Customer Service or Product Service when parts of the customer and product data are scattered over several data sources with different levels of data consistency, and without proper data matching and de-duplication? Which data source should the service pick its data from for further processing?
Without having MDM in terms of information services in place to cater for data quality and consistency, applying service oriented architecture can make the matter worse and have unpleasant and in some cases dire consequences for an organisation. This is simply due to now having services that expose incorrect, un-trusted, duplicated and un-cleansed data that is consumed by many more consumers than when there was no SOA in place. As SOA is a strategic enterprise wide initiative, MDM needs to be considered at the same level rather than a specific project implementation for a specific line of business.

Of course it is quite possible to implement MDM without services or SOA architecture. Instead of building services to maintain and retrieve the master data, ETL (extract, transform and load) tools could be used to build the required master data management solution. Data can be standardized, validated, de-duplicated and cleansed whilst it is being pushed into an MDM underlying data model. However, the ETL job batches that implement such a solution would quickly become fairly complicated in any approach to the same level of data quality as can be achieved by a set of well-designed information services.
In a rather simple scenario a non-SOA MDM approach might work but it will not have the advantages of being real-time services as “information as service” would offer. Such a non-SOA solution approach will hinder the smooth integration between this solution and the rest of the enterprise business processes as otherwise it could be easily achieved by SOA approach. Capabilities such as instant updates with proper transactional (two-phased commit, XA compliant) control would not be available. Security, data visibility, and data entitlements would be hard to control if data access is done directly to the database, and so forth.

In short, MDM implemented as “information as service” will complement the goal of service orientation and push SOA to reach its full potential for an organisation. Information that is trusted and delivered in-line and in context can be an accelerator to innovation, enabling organisations to optimize their operations, reduce their risk, and discover new business opportunities. Simply by improving visibility into business operations and core business data, companies are better equipped and armed to compete effectively. Information integration through MDM solves this by giving processes, people and applications a single view of the truth. SOA enables this single view to be made accessible to the entire enterprise, ensuring that consistent governance is always in place and enforced. It also offers more flexibility to change, by insulating application changes from information changes.

SOA wishlist for Santa Claus...(and food for thought for rest of us)

2009-12-21T08:43:28Z

I know it’s not fair to pull Santa into the SOA groove but I decided to take a shot to post my top priority wish list for SOA to Santa…just in case if this works, I may solve the world hunger (in SOA context of course) someday….so those who want to have fun, most welcome to read this post, others can take it seriously (including Santa)..]]>

Simplify the scope of SOA (and so our lives who need to deal with it day in and day out) – SOA is perfect example of the one of the ‘Doom signs’ that I talked about my another blog ” Are we growing on a fundamentally doomed DNA for tomorrow's IT eco-system” . As SOA become popular stuff, there seems to be SOA solution for everything in the life, including marriage problem (that’s slight exaggeration but you know what I’m talking about). It basically meant that the global SOA framework has millions of stuff to be designed, looked after and ‘reengineered’ to make it work in SOA way. I think that’s way too much. So if there is only one wish that Santa is going to grant, that will be to simplify the scope of SOA so that millions of engineers and consultants who are spending countless hours on SOA with clients can save lot of precious time and energy and deliver exactly as much is needed exactly how it is meant to be.

Let SOA investments be absolutely business (performance) goal driven (and given to IT to meet the goals than meeting the specifications only) – I think Santa can relate to this easily. He doesn’t give X-mas gifts to children just like that. He knows what goals he has for those children. SOA investments are somewhat like that. Many of the SOA programs don’t really have well defined business goals and in fact for many of such programs, there aren’t any expectations from business at all. That scares me a lot while nearly 60% (don’t count on this number, it just means majority of it) of the SOA intellectual teachings on the web say that SOA is all about business and yet, most of the SOA programs don’t have any clearly defined measurable business goals that are used to define, design and deploy the SOA capabilities.

Give us freedom from ‘technology minefield’ to focus on architecture and business – That’s another issue with Santa. He fortunately or unfortunately doesn’t need to rely on technology as such to get his Christmas stuff done. So he will need to spend some more time with me to understand how technology minefields are blocking the focus on the core through which value is created – Architecture and Business engineering. It seems majority of consumers are badly occupied solving technology problems in order to free up their thinking CPU for going to next step of SOA.

May every IT portfolio competently adopt SOA as core of their part of the IT architecture (and save the world from the complications of yet another competency center) – this is endless debate but because it is my wish list, I think I can be free to ask Santa to make it happen, some may like, others may not. If you fall into any of these two categories (likes and dislikes), you just can’t miss reading my another blog (and post your comments of likes and dislikes both welcome equally) “Who Needs the SOA Competency Center in this world?”

Make all the vapor stuff disappear (and bless the real stuff no matter how small that might be) – Unfortunately Santa has not spent any of his time following the fun in the IT industry so it is going to be very difficult for him to understand the problem of a thick vapor layer that has engulfed the real-stuff behind SOA across the globe. So I don’t mind spending time with him and I’m sure when he understands the seriousness of the vapor problem (no less than global warming and ozone layer depletion in my view), he may not mind casting spell to make all the vapor disappear. Current rate of disappearance is very slow and it is big time hindering the focus on what really SOA could do/should do.

Orient the top brains (and minds) towards serious and selfless collaboration to create next breakthrough innovation with SOA – I mean, how long can industry be talking about the same thing again and again and again and yet again. SOA is a good thing and it has been very kind to industry to give new hopes, new excitement and new view-points. But it got to be moving forward. We all are making small small steps for that but I think it will be just great if top brains across the globe could unite and bring forward best of the innovation in this space that can transform the industry. SOA needs it. Otherwise we all will be sitting in our own small corners and beating our own drums for all small stuff that we could do and our time will be up. We all are selfish to some extent in our business space and competitive landscape so I thought I will leverage the divine power to resolve this problem.

Save me from feeling guilty of not having “seven” wishes. It seems everyone has either top 7 or top 10 for whatever they want to say. Unfortunately I got stuck at 6th and I could not figure out what my 7th wish could be. I hope Santa doesn’t mind that.

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!

IBM SOA Stack – Scope for Simplification

2009-11-26T13:18:36Z

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.

The SOA Architectural Challenges in Practice

2009-11-15T22:27:24Z

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.

SOA Service Management (Part 1): Viewpoints of Complexity

2009-11-12T21:57:04Z

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.

]]>
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.

Has Cloud Computing given SOA another big push?[Part 2]

2009-10-28T16:20:06Z

By Brahma Acharya

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:

]]>

Think Parallel: Design your services such that they can be run in parallel. Distributed processing framework like Hadoop and Map/Reduce have made it possible to run applications concurrently on multiple nodes without much effort. Also, think if the services can be run in a multi-processor environment on parallel threads.

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.

SOA Symposium reveals SOA manifesto

2009-10-26T04:54:15Z

By Murteza Salemi

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.

]]> SOA manifesto clearly demonstrates the shift in the understanding of the SOA world toward business-centric vision of the Service orientation. It is pretty much in sync with OASIS SOA Reference Model and coming Reference Architecture (RA) standards. What significant about this manifesto is that SOA standards and best practices from different standard groups and SOA thought-leaders have started to demonstrate a tendency to merge focuses and recommended directions, which is very important and pleasant fact. The authors of SOA manifesto say that they "value the items on the right" but "value the items on the left more":

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.

Considering your SOA journey? Be aware of SOA Pitfalls

2009-10-25T22:12:12Z

One of the fundamentals about SOA that every enterprise needs to understand is where they stand today before starting the SOA journey – are they ready to take the plunge? Understanding this would give a quick overview of the organisations readiness and maturity of SOA. Thereby ensuring that the common SOA pitfalls are avoided and right strategy and associated programme/initiatives are identified for starting SOA journey for the organisation.

]]> In this blog, I would quickly touch upon the most common SOA pitfalls. The list looks very common, but on the ground the SOA team tend to more often ignore these common ‘must to do’ things due to the high visibility and demand (to deliver against a tight deadline) of the SOA initiative and excitement to work on the cutting edge technologies.

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!

Has Cloud Computing given SOA another big push?[Part 1]

2009-10-20T08:53:04Z

by Brahma Acharya

SOA has now become main stream. Organizations are slowly aligning themselves to implement SOA to realize the benefits. And then suddenly we have "Cloud Computing"; the new kid in the block. It has generated unprecedented hype. Gartner’s Senior Analyst Ben Pring has mentioned that "Cloud computing has become the phrase du joir". It is difficult not giving enough attention to it. Not to miss the wave, we see cloud vendors pop up every day providing a variety of services. It is being discussed in almost all the IT boardrooms. And rightly so, people have started to realize that this is not just any buzz. It promises to do to IT, what Internet did to business in the early 90’s; a paradigm shift.

]]>

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.

So with all these in background,

Where does SOA come into picture?

Does SOA really get affected by this new wave around Cloud?

Do the two converge?

Is it more important than ever to design applications on the tenets of SOA?

The answer to all these is a resounding YES.

SO what is ‘Architecture’ in SOA – Can we call it Legacy already?

A typical SOA architecture consists of a UI layer, a BPM layer (Process orchestration), a Service and business component layer and the data access layer (Fig-1). They are all deployed in their own infrastructure within the enterprise. The core of SOA lies in discrete services and processes. Services have explicit boundaries and solve independent business functionality. A process can consist of many of the services in a well orchestrated manner. As an example, an e-commerce application which is designed on SOA principles can consist of a recommendation service, a search service, a catalogue service, a shopping cart service, a payment service and a check-out service (In reality there are 100s of services in an e-commerce application). A buying process can then be developed utilizing a catalog service, a shopping cart service and a check-out service.

Fig 1: Typical SOA architecture

So why move to Cloud?

So we have designed our application based on SOA principles. We have achieved flexibility, re-usability, agility and greater maintainability. So why this cloud thing? It turns out that depending on how the architecture is designed we can benefit from the following Cloud features:

Cloud has significant cost benefits: This probably is the crux. Hosting applications or part of it on Cloud will significantly reduce the CAPEX and OPEX of an organization. It also reduces the lead time significantly to procure and deploy software and hardware. Important to note that it might not be possible to host entire applications on the Cloud. It would be unwise to run the mission critical applications on Cloud in entirety. There could be security or privacy issues. Being on an SOA platform gives us the flexibility to host part of the application on Cloud. What needs to be hosted on Cloud depends completely on the requirement. For ex: The entire BPM layer can be hosted on "Appian Anywhere" provided by Appian, the BPM SaaS provider. Again the services and their corresponding data can be hosted in Amazon’s EC2 and Amazon’s SimpleDB.

Cloud provides better performance with parallel execution: A Cloud platform provides the ability to run jobs in parallel. Platform like Hadoop and Map/Reduce are commonly used in a Cloud platform which can effectively run the jobs in parallel. Properly designed services, if independent of each other can be run in parallel. Also the individual services can be run in parallel if required. For ex: The search and recommendation services can be easily run in parallel.

Better SLA’s and better reliability: There seems to be some misconceptions around the stability of the Cloud services. People tend to think that Clouds are less reliable and prone to data hacking and data loss. On the contrary as and when the big players like Microsoft and Google get into this space, they bring in with them the same technology that runs their massive data centers. Most of the cloud providers now provide 3-9s reliability; 99.9% uptime. Though there have been some glitches it is bound to get better with time.

Better Agility: Moving into Cloud increases the already agile SOA based applications at multiple levels. New services can be bought from specialist SaaS vendors and can be integrated within no time. A B2C portal can run burst of digital marketing campaign without worrying about software or hardware.

Better Scalability: Auto-scaling or Elasticity is an inherent feature of a Cloud platform. The on-demand model will allow application to scale up infinitely. As such seasonal peak loads and a sudden burst in usage is handled transparently by the Cloud.

Fig 2: SOA + Cloud

It is important to note that having followed an SOA based architecture it becomes easy to move various aspects of the application to a Cloud. Figure 2 depicts one scenario of a hybrid environment of SOA and Cloud. The permutations and combinations are literally limitless.

In the Part 2 of this blog, I will talk about the design considerations when you are looking to exploit the Cloud while doing SOA.

‘SOA Security’–How much is enough?

2009-10-19T11:45:22Z

by Animesh Ghosh

‘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.

]]> SOA security is a complex matter, but my suggestion is not to become overwhelmed by security buzz words. Focus on ‘what you need ‘, not on – ‘what is available in the market’.

Below I have listed my thoughts according to the priority, I think, organization need to think while researching about "SOA Security – how much is enough?"

First understand the boundaries and decide what security vulnerabilities are critical for your organisation.

Every security risk may not be applicable to you. Focus on vulnerabilities in the ‘OWASP Top 10’ (www.owasp.org) which are known to be common and critical. Many of the vulnerabilities found by security analysis technologies are not likely to occur.

Centralize and Externalise security concerns – this is very important to effectively mange security.

Make sure ‘Security as a Service’ available ~ 100 %, as Security Service is the gateway to all other services.

Stay compliant to standards – very important considering heterogeneous nature of the SOA components.

Use XML signatures and encryption to enforce message level security when exchanging data with partners

Consider credentials encryption without encrypting the whole XML data structure when the content is not highly confidential.

Each time you identify vulnerability, determine its root cause and create a static analysis rule to identify all other occurrences of that same root cause.

Always implement effective Logging and Auditing features to catch security breach

Avoid Denial of Service (DOS) attacks by employing solutions such as XML Firewall and appliances

Treat security vulnerabilities as high priority (severity- 1) bugs—bugs that are critical enough to stop a release. Just one security vulnerability could open the door to devastating attacks.

Look for SOA security solutions those are designed to interconnect effectively with existing security functionality.

Consider implementing a SOA security solution that enables SOAP message monitoring; federated authentication; application proxy; contract management; certificates, keys, and encryption; and audit logging.

Adopt incremental technology delivery and maturity-based approach (expect mixed and hybrid environments)

Remember security can create tight coupling in enterprise SOA and can degrade performance

Service Category – The world of Confusion

2009-10-16T08:50:49Z

by Murteza Salemi, Shubhankar Sumar

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.

]]> The best approach is that every organisation or business unit identifies and agrees on a glossary of these terminologies and definitions right at the beginning of SOA journey. On the agreed category, create guidelines and characteristics for each category for ready reference. The same is communicated and mandated by the SOA governance team within all the SOA programme within the organisation.

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.

Some thoughts on Service Naming

2009-10-15T08:53:47Z

Every web service Designer and Developer possibly have come across service naming standards or best practices in one form or the other. While I do not want to dispute the fact that standards are needed for enforcing good practices that goes a long way in software maintainability and manageability, but then trying to follow a standard without completely understanding the philosophy behind it may not produce optimal results. Now, I do not want to get into pros and cons of particular semantics of service naming either, e.g., naming conventions such as using a verb+noun pair for naming a service, using camel case etc. I will pretty much follow those widely used conventions without a debate. I will rather try to throw some lights on the common-sense and practical factors that may make service naming less creative and more predictable. Comments and debates welcome.

]]> So thinking with a clean slate – here are some thoughts. IMHO, a good service name should have the following classic attributes (I would not blame you for thinking that I was influenced by OO programming principles in more than one ways):

Service Naming is part of Service Design. Hence one should understand the complete context, functionality and the Layer of abstraction that the service belongs to in a Service Oriented Architecture. Is it a top-level business orchestration service? Or, is it a much lower level service? Or is it a technical service across business domains? After identifying the Layer a service belongs to, it is easy to

Predict its usage scope
Identify its potential consumers

And hence the naming can consider making it contextual to the consumers. After all, service discovery is not too far.

Service Name should attempt to portray the functionality of a service in the light of the overall business process context. So one needs to answer questions like what business logic does the service provide? What business processes does it support? If the service name fails to give you flavor of the business context (or, technical context if it is a technical service) then something is missing. Essentially you should use a verb to represent the actual business task carried out by the service with as much context as possible. Additional context may come from using an appropriate Entity name in the service. Let me site a couple of examples; I would prefer a name that provides more contexts. Lets take the example of service provisioning process for a hypothetical teleco. Let us say a service is used by the process to establish is the customer address is serviceable. This process of customer address validation along with few other steps is generally known as service qualification. Hence QualifyServiceAddress is a better name for our service than something like ValidateAddress because it is contextual to business and has describes the service more accurately.

The other important thing is to use only standard entity names in your Service Name. When I say standard entity names, I assume that an organization-wide data model/information model/business information model already exists. So re-use the same vocabulary and adhere to your organizational standards.

Now as a disclaimer, I think no amount of standard is sufficient to ensure good naming. In many cases just following the semantics, without understanding the principles, beats the whole purpose of naming standards. Let me site some hypothetical examples; you might have come across situations where a new service is being designed to expose or replace a legacy application. The name of the service many a times would be influenced by the application names or process names of the legacy application even when the service interface may exposes a miniscule part of the application. In this case, the service name largely misrepresents its functionality offered. Or, how about a very long verbose service name that attempts to specify the entire business context in its name and does very little. The examples can go on.

SETLabs and Infosys participation in SOPOSE workshop AT Services Computing 2009 conference

2009-10-13T08:15:07Z

I was the chair for SOPOSE 2009, the fourth international workshop Service and Process oriented Software Engineering (http://www.dsl.uow.edu.au/sopose/index.php ), the workshop co-located with SCC 2009. The workshop aimed at addressing software engineering issues related to constructing service oriented architecture and business process management.

]]> The workshop started with a keynote by on Value in Services Systems, by Prof. Joseph Davis, of Univ of Sydney. This talk focused on the conceptual foundations what has come to be referred to as 'service science' which is concerned with the design, value co-creation (between the service providers and customers), and performance modeling of complex service systems.

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.

Rethink your approach for implementing SOA initiative and it will have higher chance of success

2009-09-30T12:41:10Z

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.

]]> By ensuring that the there is a tight link between business and IT, with resources that understand SOA principles and can collaborate as part of a joint program, you minimize the risks of deviation from target set for the initiative.

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.