Service-Oriented Architecture

Adoption of SOA is growing faster and faster. But whenever an organisation adopts new approach/framework/technologies, mistakes are likely, and SOA is no exception to this rule. I have been personally involved in quite a few big SOA (Service Oriented Architecture) initiatives. Keeping the trend of mistakes, organisations and I have experienced those and tried to rectify those in the subsequent ones and thus those become part of the best practice. Even though organisation starts with a big dream of SOA with Strategy, Roadmap, Value add to business etc etc, there are number of key important best practices to be followed which have been experienced by the industry, are above and beyond just having SOA Strategy and Roadmap at the beginning. So, it's very important that the experience of the early adopters of SOA is captured for the benefit of those who are planning to adopt SOA in the near future. Identification and documentation of all those processes / policies / technology / best practices that is most essential - will help enterprises avoid mistakes and successfully implement SOA. I have captured few of the processes / best practices which must be in place for adopting SOA in an enterprise.

Most important ones are listed below. Some of those you might have already taken care while others are looking for complete list.

 

1. Think Big but Start Small: Most of the organisation I have interacted with seems to be in real rush of realising the benefit of SOA as early as in just 2-3 months and that sets the expectation too high. This essentially in turn moves the attention from building the base SOA infrastructure towards implementation. As a result, lose track in the mid-way and eventually blames SOA for NOT being able to full fill the expectation. Instead, select a well thought of ‘Pilot’ (i.e. set of use cases) which captures end-2-end flow of the business and would have visible impact (Ah Ha! effect) and tangible RoI. Implement the pilot on a well established base infrastructure. Use the experience of the ‘Pilot’ to enhance your SOA processes (Governance, Service Life-cycle, Technologies, etc.). In the recent Gartner SOA conference in London, the same sentiment has been echoed by different organisations who shared their SOA success story.

 

2. Governance key to success: SOA without Governance is the perfect recipe for failure. SOA without governance is like ‘class full of brilliant students without a teacher’. SOA is lot more than just creating bunch of services. There is the whole notion of infrastructure & processes on which those services will be running & managed and external system with which those will be interacting with. To manage the complexity, there has to be a governance process based on well defined standards, policies and processes along with reviews, checkpoints, and metrics.

 

Don't take any short cuts when it comes to governance. You may eventually get there but it will be much harder to implement things at a later date. One can get there today, but several months from now on when there would be over a hundred services and a dozen projects in production, you better have this resolved now or you will be sweating hard then (and forget about the benefit of SOA) instead of working smart.

 

3. Govern policies that matter most: Policies are must to have to make the Governance easier and making SOA deliver the intended result. However, having too many policies and treating them all with same priority means ensuring things would not be delivered early (some cases never). So, it is imperative to focus on policies which are critical to making the business, IT and other involved parties work together for success. Focus should be to meet the customers’ expectations/needs and ensure that they are getting the same. Having too many policies is like ‘making every word bold in your email to highlight the message’ – defeat the core objectives. Having too many policies is just as ineffective as having none (maybe worse).

 

4. SOA is expensive: Bear in mind that SOA is not cheap. Building & managing reusable common services is expensive. As per the industry experts, making services re-usable is 2.5 times more expensive than building a software component. Then why SOA getting so much of attention? The fact is getting SOA working with first set of well designed services is expensive, but once you are running with SOA changing your business (fulfilling your business demand) is much faster and you start realising the benefit.

 

5. Make governance easy and do it early: Have governance in place early in the SOA adoption and follow the ‘KISS’ policy. More and more organisation have started realising the importance of having governance right at the beginning while SOA makes its journey through Gartner ‘hype’ to ‘disillusionment’ to ‘slope of enlightenment’ phases.  Getting Governance right at the beginning (integral part of SDLC) reduces confusion and rework while governance becomes an integral part of the SOA journey without being a burden to the whole SOA team.

 

6. Get your Communication tool in place – Develop common terminology: Not a new ‘mantra’. Like any other abstract architectural approach, when talking about or arguing over something as abstract as SOA, just talking over phone or meeting in the coffee area is not going to do the job. Get it documented – use tools wherever possible. SOA team should use tools (Visio, Modelling tools) to capture the ideas – like service life-cycle, service orchestration etc – to get agreement faster.

 

7. Getting the right Interfaces are key: Don’t worry too much about your implementation of services. Well defined interfaces (with right strategy for versioning etc.) would make or break your services. One can implement the actual services in whatever way (technology, infrastructure etc.) they want which really does not matter as those are completely hidden (encapsulated) behind the interfaces. It’s unlikely that SOA would be ‘greenfield’. Most of the cases, SOA is a migration. So, keeping the focus on Interface is much more important than anything else.

 

8. Each service should have owner: Decide the ownership of the services upfront – again one of the aspects of Governance. For every service, ownership has to be defined at two levels - Business and IT. Business owners are responsible for the business capabilities of the services, including the cost of running it, and its value (business) proposition. IT owners are responsible for development, maintaining different versions of services, ensuring the service level agreements (SLAs), and making sure consumers of the service are satisfied with it.

 

9. Be pragmatic: No need to be perfect. Achieving perfection in SOA would make SOA journey towards failure as business would not wait for eternity for IT to deliver perfect SOA. Deviations are inevitable from SOA best practices and your organisation is no exception. So, need to have a plan on how deviations will be dealt with and accordingly tracked as part of the governance process.

 

10. SOA is to change Business: Treat SOA as a business opportunity not a re-platform program. So start with business process design – a top down view – which would provide right insight into what business services to be designed. This would help to get business view of SOA right at the beginning and be easier to manage business stakeholders

 

11. Managing Stakeholders key to success: Setting the expectation to key stakeholders (Business & IT) and keeping up to that is must for successful SOA. Every stakeholder would have different expectation (in terms of benefit) or see SOA differently – like ‘the Six Blinds and Elephant Story’. However, we need to ensure that everybody understands the value proposition SOA is bringing on the table and aligned with that. This would help addressing the funding challenge and buy-in by showcasing the strategic value of SOA while having very clear roadmap to move towards SOA journey. This would eventually help the Organisation to achieve the business value of SOA collectively.

 

Even though all these are good to have, Governance is KEY to 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. Accordingly, decide what is to be enhanced to address those which are not going in the expected way and move towards success.

Hope I have provided some useful thoughts on how to avoid known mistakes in a SOA programme. In my subsequent blogs, I will cover where and how to start SOA journey.

Posted by Shubhankar Sumar at 01:34 PM | Permalink | Comments (0) | TrackBacks (0)

Intel has released some new numbers, as they noted in comments to an earlier blog entry. These are some highlights:

 Decryption, Application of XACML policies, routing to different SOAP services: 1050 messages of 7.64 KB processed per second

 Legacy to SOA Integration use case: 980 messages per second for a healthcare HL7 format messages

Mediation use case: 5184 messages per second, including validation, transformation, SOAP message generation. 

What additional windows of opportunity do XML  appliances of  such speed open up?

I would love to hear your thoughts and ideas about this. With processing speeds of 50 to 100 MB per second, and about 5000 messages per second secured- what additional possibilities does this open up?

Are there areas where XML formerly could not compete, but now can? 

 

 

 

Posted by Kevin Apte at 02:47 PM | Permalink | Comments (0) | TrackBacks (0)

I’m calling it a story since it is yet to happen…more ambitious word for this will be ‘vision’.  But given that ‘SOA’ and ‘vision’ have been beaten to death in last couple of years so let me continue with the story only. Key word in the title really is not the ‘story’ though..it is the ‘main-stream’ and soon you will see why. One of things in SOA that make me sick is the ‘real-ness’ of it (or rather lack of it). I personally feel that SOA as a concept is running out of steam to remain in the ‘hot seat’. There isn’t much new or different coming out from it than what has been spoken about thousands time already in difference styles and with different jargons. For that matter, I think ERP as a concept has done far better where in journey from speculative vision to physical realization (what so ever it has been, that really doesn’t matter) has been rather fast and it did change the shape of the industry to large extent. With SOA, industry seem to going on and on and on but like everything else, SOA will run out of the fuel sooner or later. If industry doesn’t something new in SOA which is the next level of life with SOA, it will not sustain. Skeptics are already ignoring it, even believers might drop the ball after a while. So what do we envision beyond this?

I think BPM is going to be a great savior for us. What I see happening is very sensible and natural in my view. SOA hype will diminish, BPM hype will gain strength. Though SOA hype today is far louder and taller than BPM but on the ground for sure BPM implementations are more real. When BPM will catch the steam, SOA will get a place where it really belongs to – a service enabling framework for BPM..:-)…so in that scenario, SOA will be a de-facto architectural construct in terms of standard architectural policies and design styles that will be utilized to make enterprise BPM happen. Given that BPM is really much closer to the business (closer than what SOA claims to be or could ever afford to be), it will be truly drive the change in the business solution designs. And when doing so, it will be able to leverage the appropriate stack of SOA enabled technology including EAI and B2B. That’s what will bring SOA in the mainstream. SOA will become the DNA of the Enterprise Architecture layers and will not need to be called out separately.

What it really means that our reference architecture of enterprise business automation will be truly complete where BPM will be in the driving seat and SOA will be the magic behind the machinery operating underneath. Today, BPM, SOA, EAI, B2B etc. all are reasonably fragmented and are trying to create the big picture for the enterprise in their small world..(what a contrast!)…in my story, this big pictures of the small worlds will slowly dissolve and the true big picture will emerge where all small words exist in integrated manner, in the place where they belong. And naturally, BPM will have the business impact measurements as the KPIs which will percolate into all layers beneath, be it SOA or ESB or EAI or B2B.

In my assessment, this has started happening already in pockets and it may not take more than another 2-3 years before it comes true in grand way.

Posted by Rakesh Mishra at 04:42 AM | Permalink | Comments (2) | TrackBacks (0)

As a SOA Architect, I certainly do not approve this. But here are the top 10 ways you can "Fake your way to the SOA-XML bandwagon. "

In some companies SOA has been oversold, or may be premature. For example, Security and Fine Grained Entitlements are  so critical in some financial institutions, that without this piece in place, it may be premature to talk about SOA. Or may be the data still exists in silos, making it impossible to construct meaningful useful services, that address the immediate business needs of the organization.

But  if you are under pressure to be supportive of SOA and XML, here are some ways.  

 

Yes, we use SOA and XML.

10. We use ant based builds, and our build files are in XML. Therefore XML And SOA has penetrated our enterprise.

9. We use XML based configuration files for our application servers. 

8. Some of our JMS messages are XML based, Others use Map Messages, but we could convert them to XML easily. 

7. We are using industry standard canonical models, they are in XML. The canonical model covers only a small part of our business, but if a better canonical model for our particular industry, and for the way we do things was available we would use XML.

6.  We have business rules engine package, and the rules are stored in XML

5. We have some reports generated in XML before they are converted to PDF automatically. 

4. We have an ESB, and 2% of our messaging traffic, goes through the ESB.

3. 0.4 % of the traffic is in XML.

2. One application routes its messages dynamically in XML

1. We recently upgraded to Office 2007, so even when we write a Word document, we are using XML. 

The last point about Office documents being in XML and therefore "SOA compliant" could perhaps be  perspicacious and visionary rather than facetious and tongue-in-cheek.

Consider a law firm or a pharmaceutical research group, or a financial services companies- or even a transportation and logistics company, that gets all its customer/supplier documents in  Office 2007 format- where does the knowledge critical to the business reside?

In another blog, I will try to show you how even if your enthusiasm for SOA is limited to potentially  saving your Word 2007 document in  XML form- you  could still be  moments away on the SOA bandwagon.

 

Posted by Kevin Apte at 09:02 PM | Permalink | Comments (2) | TrackBacks (0)

Is it necessary to have an advanced and  mature SOA Stack in order to have centralized security policy creation and enforcement?  If a SOA Stack is not at a stage where Composite Applications are proliferating, is centralized security still required?

You need centralized security policy creation and enforcementet quite early in your SOA program. The first step in your SOA initiative will be to decide what level of granularity your services should be at. It is very easy to create webservices using built-in wizards found in many IDEs as well as wizards offered in products like databases and portals.

This leads to service proliferation, leading to a “Forest of Services”. The best practice therefore is to create coarse grained services, with the service mapping to an enterprise level entity like “Customer” or “Supplier”.

This immediately creates a security issue.

If all of the customer information, including sensitive private information is in the same XML object, how can I enforce security? How can I enforce role based security?  Where should role and enterprise policy based security be administered from?

For example, you may say that only people “Sales Manager” and above, are authorized to view past customer purchase information. Only “Customer Support Manager- Level III” and above, can see customer private information.  Remember, this is not about encryption but “View Privelege”.

It is possible to enforce this in custom code at the service level, but that would be a maintenance nightmare. If you want to change policy and give access to Customer Private Information to all “Customer Support Manager- Level II”, it would require a code, or at least a XML configuration file change, and service redeployment, with all its problems(Finding a maintenance window everyone can agree on, Obtaining builds before the Maintenance window in order to test them)

Changing policies at the centralized level is much simpler.

Does IBM have solutions to help with this?

Yes, IBM as well as other vendors, have solutions to protect XML data at the field level. This is not about encryption of the data, but about granting the privilege of accessing the data at the field level, based on organizational role and enterprise security policy. For example: Forum Systems , IBM DataPower  Layer 7    have appliances that can protect data at the field level.

XML Security can also be implemented using ESB level mediation in application servers such as Websphere.

What about Database level security that is role or Enterprise rule based?

Oracle has a product called “Oracle Virtual Private Database” that can enforce database security at the Enterprise level.   DB2 has “Label based Access Control”  which does not appear to be as flexible as Oracle VPD.  These products need to be integrated into the SOA Security Reference Architecture.  

So where is the gap in the IBM SOA Security Reference Architecture?

The gap is that the Security Reference Architecture does not provide a way to leverage the technologies above.  Additional Architecture Building Blogs are needed to  create a scalable, Performant, maintainable, extensible and standards based way of  administering Enterprise Security in the SOA Context.  It should support central administration with security policy delegation.

Why can I not use Tivoli Federated Security?

Tivoli Federated Security allows you to do single-sign on onto multiple systems. It does not provide a way of enforcing security policies at the enterprise level, or to delegation.

In the next blog entry, I will describe the missing Architecture Building Blocks in greater detail, with a Visio based diagram.

Posted by Kevin Apte at 09:14 PM | Permalink | Comments (0) | TrackBacks (0)

Why do we need different Architectural Building Blocks to specifically address SOA Security?  Should the best practice of “Independent Chain of Command” be part of SOA Reference Architecture? These are some of the questions and comments, I have been asked in response to the first part of this series.  SOA Security must handle the highly composite nature of today’s and emerging SOA Applications, and this ability to handle composite, frequently changing, dynamic applications is a critical requirement for managing security in SOA environment.   Maintaining Security Accountability in the context of   composite applications that cut across IT business unit, Enterprise Application, databases is a key challenge for SOA Security.

"Composite applications are also eroding the definition of what an application is. In a SOA world, an application’s features, composition, location, and communications are no longer predetermined or even well-known. Instead, an application becomes a changeable collection of dynamic software services, with transaction paths that are determined on the fly from business rules created by business managers." (Jasmine Noel in Software magazine) For example, a composite Customer Dispute Resolution Application may combine customer data from three CRM Systems in an enterprise, clean the data with an external WebService like Trillium , and then join the cleaned data with a legacy enterprise database. Who is responsible for SOA Security in this composite application?
	Composite SOA Applications are a key to realizing the Business Agility and IT Flexibility promised by a mature SOA Stack.   The diagram above shows a Business Process Composite Application. (Source: ClearApp)
Each of the 3 CRM systems and the legacy database have the respective administrators as security gatekeepers. But extending this paradigm to the Composite application will lead to unclear authority and diffuse accountability. This is why it is critical to have an “Independent Chain of Command” to enforce security policy. Since the “Security Policy Group” cannot administer security on a day-to-day basis, the architecture also has to provide ways by which the Security Authority can be delegated (and revoked) to the IT or Business Unit groups.
In the next entry, I will describe the Architecture Building blocks needed to implement  a centralized Security Policy Administration group.  Further Architecture Building blocks, can demonstrate delegation of security authority to IT and Business groups. (Troubleshooting and administering Composite SOA applications can also be a challenge. ClearApp has an interesting solution, but that is a subject for another entry. )

Posted by Kevin Apte at 05:28 PM | Permalink | Comments (0) | TrackBacks (0)

Gartner predicts that by 2010, 80% of software revenue growth will come from SOA enabled applications.  With such enormous potential, IT firms are constantly trying to ramp up their potential to deliver SOA as per their clients' need.  SOA is a hard sell as it involves an intimate understanding of both the client's business and their IT landscape.

From an IT firm's perspective, success in selling SOA is dependent on the ability to show customers value, both in terms of the benefits they can realize through SOA, and the value that the IT firm delivers when deploying SOA. To understand it better let us look it from both customers' and IT firm perspective-

a. Customers - better visibility on their business, more control over their IT systems, automation, newer opportunities, best sourcing options, quick reaction to market trends, extracting more value out of existing applications

b. IT firms - Agility to assemble solutions, productivity improvement due to reuse, modular delivery, lesser cost of development, Less time for building due to standards, The key challenge in front of IT firms when they have to sell -

1. Be able to hook on initially and make sure the initial traction on SOA is not lost amidst various transformation initiatives

2. Translating the promises into credible instances (like quick proposition or proof of concepts) so that SOA is not interpreted as 'snake oil applied'

3. Identify immediate and long term benefits which shows either direct or indirect value in service enabling

4. Advising or providing prescriptions for client's SOA program by appropriately positioning the technology and products

5. Identify the entry points for SOA adoption and defining appropriate pragmatic approaches

6. Understand the disparity amongst the aging systems and provide guidance on appropriate infrastructure

7. Channelizing the direction of SOA adoption through governance with organizational involvement

Common barriers to adoption of SOA that are currently being cited are

• Lack of clarity of the value of SOA investments by business owners

• No clear understanding of how to plan for and execute a SOA adoption strategy

• Sense of frustration with the current state of IT architectures

• A strong realization that architectural limitations are often a major hindrance to strategic business innovation.

McKinsey reports that “Today’s IT architectures, arcane as they may be, are the biggest roadblocks most companies face when making strategic moves.”  The same could be the biggest challenge for IT firms as well to jump on to clients' SOA bandwagon...

 

Posted by Naveen Kulkarni at 03:35 AM | Permalink | Comments (0) | TrackBacks (0)

 

Recently,in the context of a client request, I had a chance to look at the IBM SOA Security Reference Architecture, described in this redbook. I found some critical gaps in the reference Architecture. I will highlight these gaps in this and subsequent blogs. The first gap is that the SOA Security Reference Architecture, does not consider supporting an Independent Chain of Command for managing Security Policy. The second gap is that it does not explore the use of right architectural building blocks to enable externalization of Security policies outside of applications, portals, databases, data services, service components and; Business Processes, The third gap is that it does not recommend the right set of tools with which enterprise grade SOA Security, based on the the two principles mentioned above can be implemented. With these gaps in place, demonstrating and maintaining compliance with regulations and laws will be difficult. In this blog, I will describe the concept of Independent Chain of Command in detail, I will describe the other gaps in the next two entries.

Traditionally, IT security has been handled by IT, because of the technical skills required in granting and revoking privileges to enterprise users. Often, the IT staff who are providing application or database level support, are also responsible for administering security. Sometimes, business users are responsible for administering security. Very often, IT staff whose performance assessment and bonus depends on business users they serve, are responsible for enforcing and administering security. Sometimes, the organization is designed so that IT staff report to the same person as the business user, possibly in a dotted line relationship, or in a matrix organization. This creates a clear conflict of interest, and potential for abuse.

I have heard of some small hedge-funds where the IT person administering security is highly motivated to give excellent customer service to hedge fund traders, with a bonus that may be up to 150% of his salary. This is highly desirable from an organizational perspective, except from a security perspective, this scenario is a security breach waiting to happen. This may be an extreme example, but conflicts of interest are common when security is not being handled with an Independent Chain of Command.  The best practice there is to implement an "Independent Chain of Command" for security. In this paradigm, the Security Policy Administration, is handled by a group that reports neither to business, nor to IT- but to an independent senior level executive, such as Chief Financial Office, Comptroller or Chief Corporate Counsel. This prevents conflicts of interest from compromising security. This is depicted in the diagram below. The diagram illustrates the Independent Chain of Command best practice, essential for strong security and SOX compliance. Please click on the diagram to see a larger version in a different window.

 

 

The key points of this best practice overlooked in IBM SOA Security redbook, are in light blue in the diagram. The highlight of the diagram is: Primary Security Authority is with Security Policy Group. The Security Policy Group can delegate appropriate authority to Business and IT groups. SOA can allow rapid creation of services and composite applications, but these composite applications may be in breach of various organizational policies. In a SOA Security model, therefore,  security policies cannot be opaque and embedded deep inside application code, or in obscure stored procedures.  Achieving this may seem difficult, but numerous tools, standards and best practices can make this a lot simpler. They will be outlined in subsequent entries.

Posted by Kevin Apte at 09:52 PM | Permalink | Comments (3) | TrackBacks (0)

I can almost call it a trend as I see it happening again and again, case after the case. As soon as enterprises get active on SOA, apart from SOA technology platform and business service pilot concerns enterprises get their ideas bubbling around ‘SOA competency center’. It is an invariable expectation of having some sort of competency center that will give the enterprises whatever they want from SOA. Let me spend few paragraphs here to bring certain perspective to those who might be seriously attached to the competency center for SOA and might be seeking some direction.

To start with, first of all, I don’t believe that there is really something called SOA CoE or SOA Competency Center that can work in real-world. Well, hold on; I have not competed yet. J..if you understand SOA, you will realize that SOA is like a school of thought, it is like a religion or better yet, it is some sort of a methodology for IT solutioning. It is not a new domain in the enterprise architecture like applications, systems, integration etc. Point I’m trying to say it that if enterprises adopt the SOA, the architecture stack in terms of domains (applications, infrastructure, integration, data-stores etc) doesn’t change. What really will happen on the ground through SOA adoption is a metamorphosis of the existing EA stack domains to incorporate new methods and principles in what each of the domains does. Now, this is important to appreciate it because  a typical competency center really is a powerful idea to create some sort of shared services structure in the IT organization to deliver a EA domain specific services. Now if SOA is not going to create a new domain in the EA reference stack, then what is this SOA competency center going to do? SOA will influence and result into some new way of doing things for all existing domains in the EA stack. For example, who application designing and solutioning is happening will see some change to adopt SOA. Similar how integration and data stored play a role, some changes will, happen there to adopt SOA. So in simple terms, all EA domains will be ‘SOA-fied’ (few much more while other less and some may not be for now) to collectively make the enterprise SOA enabled.

So here is how I think whole matter can be approached in more pragmatic manner with getting obsessed with the idea of competency center for SOA. To start with, I could like to differentiate a CoE from competency center or service delivery center as I would like to address it more appropriately. A center of excellence as name suggest is more focused on bringing excellence to few aspects of the domain for which CoE is being built. In general, it will be founded around establishment, management and governance of the core methods, standards and blueprints that are required for any specific domain/discipline to bring excellence. At the same time, service delivery center will be more focused around end-to-end services delivery using a shared services model. So with that definition, surely in the existing model of IT service delivery, SOA competency center or SOA service delivery center doesn’t make as much sense. But let me say this also. As strategic long term picture how I would envisage enterprises moving to, a Business Solution Delivery Center is more promising idea that is built on principles of SOA and has integrated competencies of business and IT. Which means, sometime in future, enterprises will have a common entity in the organization that drives the end-to-end business solution by integrating elemental shared services like applications, process integration, infrastructure, business etc. But for now, I’m leaving it as futuristic idea since most of the enterprises are years away from it. To make the approach easier, let us look at three stages where enterprises might have to think of SOA competency center:

1. Very early days of SOA adoption – this is when enterprise has just thought or heard of SOA and it is trying to find ground and explore the direction with it. Now at this stage all that is needed is to get better understanding of what SOA is all about, its relevance to what it promises to change in the organization and various technological options that it has to explore. At this stage, enterprises should create a focused team that is tasked with this exploration task that might involve collaboration with product vendor, external SOA consultant and other industry SOA forums. This team is largely part time allocated on to the SOA initiative, however might have one or two fulltime allocations to provide rigor and ownership.
2. Enterprise-wide SOA program being run for SOA adoption – this is when enterprise has done some due diligence around SOA strategy and is now ready to go on with the organizational change necessary to bring the enterprise at large to SOA-ready state. At this stage, different IT competency centers like CRM competency centers, SAP competency centers, BI competency centers etc . will need to be prepared to deliver their bits for making SOA work according to overall SOA reference model. On top of that, organizations need additional support to establish common directions and strategies for SOA and subsequently govern what each of the competency centers are doing. At this stage, there are two levels of effort required. At one level, enterprises need to continuously establish SOA capabilities. At another level, it needs to engage other competency centers to adopt and deliver the SOA results with overall governance. For this to achieve, all individual IT competency centers will have their small centers of excellence for SOA specific to their responsibilities of SOA delivery. At the same time, Enterprise Architecture group will have additional roles and competencies of SOA in order to drive the enterprise level SOA. So in this case, there is no separate SOA competency center is established. Instead, it is like a SOA adoption task force consisting of EA group, business groups and IT competency center representative that need to come into existence. It is more of a transient program structure as opposed to a fulltime independent service delivery center.
3. End-state of the enterprise with SOA – this is when all that was supposed to happen, has actually happened and enterprise is now running in SOA-enabled state. To large extent, focus and structure is not much different than previous case but there will not be any transient structure in this case. Since SOA is reasonably in the DNA of the enterprise, there will be very little governance structure needed while most of the responsibilities of SOA delivery will be taken care by IT competency centers for their respective role in overall SOA delivery.

With this, my take is that setting up a proper SOA program structure for first two stages is more important than actually setting up a dedicated service delivery center for SOA. However:

• It is essential to focus on the excellence part of the SOA delivery in terms of adherence of SOA standards, metrics of SOA success etc. through appropriate governance structure. It should be housed in the EA group.
• SOA brings in responsibility of designing the business solutions effectively using services methodology for which business analysts should be taking the ownership.
• A capable SOA infrastructure in the enterprise includes strong service orchestration, composition and delivery platform. This is typically housed in the Integration / ESB domain of the EA. I see this as a significant part of the SOA game plan. And hence to large extent, what I would liked to see in the SOA competency center should be taken up by the existing Integration Competency Center. That way, an Integration Competency Center that has been upgraded to provide all necessary SOA infrastructure for service orchestration, composition and delivery will be what I would see as a the SOA competency center. It will work very closely with the previous two core structures to deliver full SOA compliance Business- IT solutions.

To me it made perfect sense to approach in this manner. But again, I will be glad to hear the alternative perspectives.

Posted by Rakesh Mishra at 04:06 AM | Permalink | Comments (2) | TrackBacks (0)