Preparing the IT Organization for SOA
Brenda Michelson, in her eBizQ blog, is encouraging a collaborative discussion around Business Driven Architecture. The first question posed by/to the blogosphere was on how to prepare your IT organization for Service Orientation.
MarkG’s stated that his “gut feeling says that IT shops that have a well established EAI practice or maybe have successfully embraced OO design will have the right mixed[sic] of governance and discipline to have a run at SOA.” On this, I have to disagree. I think a strong background in these technologies will assist in building service-oriented applications, but I don’t think it will go very far in yielding service-oriented architecture. The reason for this is that as long as all of the IT effort remains within the constraints of a single project, the organization will never understand it means to be a service provider. When a service provider and a service consumer are both working within a single project, the importance of these roles can be diminished, because there is close collaboration. Furthermore, the roles probably disappear when the project ends. What happens what the next consumer comes along? What happens when a project needs a service from a group that isn’t actively engaged on the project? How does the organization manage a service whose business logic spans multiple groups within the organization?
To me, the ability for an organization to succeed is going to be highly dependent on their ability to communicate, collaborate, and manage the service lifecycle, independent of whatever technologies are involved. I had the opportunity to comment about this in a recent ZapThink podcast. Please give it a listen and share your thoughts.
7 Responses to “Preparing the IT Organization for SOA”
Leave a Reply
Excellent points Todd. It makes me think that when addressing SOA conversations, it’s important to distinguish between the technical aspect and the business aspect.
One thing an EAI competency center helps with is a larger view of the business as well as the various projects within an IT organization. These centers often have a much better view of the world than individual development groups within an IT organization. It helps with some of the inherent communication/collaboration issues that are part of an IT organization. This can extend into the business as well but it doesn’t always which can be a problem.
This one group however cannot transform the entire IT organization however, which is the thought behind my original post. How do you get your IT organization to that state which you are describing? I haven’t listen to your podcast yet so if you have already answered that sorry.
How to prepare for Service Orientation…
…
Competency centers are an interesting beast. They definitely have something in common with SOA in that no two organizations define them in the same way. You’re absolutely right that they have the potential to help with some of the communication/collaboration issues. The challenge, however, comes back to ownership. If your competency center model includes service ownership, what domains will the competency center cover? Is it realistic to expect a single group to have the necessary breadth to cover all possible services? I don’t think that’s realistic. An integration competency center is focused on one particular domain, one in which the role can be more about mediation than actual service domain knowledge.
So, this still doesn’t answer the question of how to transform the organization. Here’s where I concur with Anil. It all begins with an understanding of the business. If I think of the typical IT project, there are so many constraints that are placed on the project from the very beginning that are impediments to achieving SOA. The way to get around them is to think outside of the box, beyond the constraints of the project at hand. How do we get staff to do this? To me, the answer is business process analysis. The staff must understand the business process into which the solution they are building fits.
To start that process, I encourage asking three questions to the development team.
1) What services does your solution use / expose?
2) What events does your solution consume / publish?
3) What business process(es) does your solution support?
You should never receive a “no” answer to any of these questions. The staff may reply, “I don’t know,” which is an opportunity to educate.
I like those questions, Todd! Please note that I am going to be ..ah.. borrowing those for use 🙂
I think that one of the things that is inherent in question 3, is if there is agreement between both the business and the technology side of the house that the solution does indeed support the business side of the house. All too often, I’ve seen solutions implemented by technical folks who *think* that they have solved a business problem, when in reality they have not from a business perspective.
BTW, I’ve taken a shot at addressing Mark’s second question as to whether or not if it possible to get too hung up on the business process mapping to not get to the execution @ http://www.aniltj.com/blog/2006/06/21/HowToPrepareForServiceOrientationPartII.aspx
[…] I think this area is one that is ripe for opportunity. I commented about this last year, but this topic still hasn’t received much attention from the vendor community. Mindreef was heading down this path back in Dec. 2005 with their Coral product, but there’s no mention of it on their website anymore (perhaps it was incorporated into SOAPscope Server). The challenge with lifecycle support for vendors is that it has to be about integration. Any product that tries to own the entire lifecycle will probably struggle. I see this space as being a combination of workflow/bpm, registry/repository, service management, and a service lifecycle management tool, at a minimum. […]
[…] Preparing the IT Organization for SOA: This is a June 20, 2006 response to a question posted by Brenda Michelson on her eBizQ blog, which was encouraging a discussion around Business Driven Architecture. […]
[…] before and after states, as well as some tactical steps to get there. In a comment I made on one of my own posts from quite some time ago, I spoke of three questions that all projects should be […]