Part One Sweeney discussed an architecture-driven SOA paradigm, and what's been holding back adoption of this type of approach. Here in Part Two, Sweeney discusses the cultural, organizational and operational impact of an architecture-driven SOA, and why the SOA architect needs to step up and lead.
Why do you think architectural restrictions have slowed SOA adoption?
Sweeney: [One reason] is a level of immaturity. The other issue is that there is a lot of push toward not adopting/addressing those things [architectural concerns]. If vendors want to sell you an ESB, are they going to tell you that's low-hanging fruit, that the reality is it's a short-term deliverable with short-term value? They won't tell you to establish an architectural practice and build competencies, because that's a much longer delivery cycle. Technology is the least of your issues; the technologies are there but they're just a tool. First you need the architecture, then apply the tools; that's really the disconnect.
Look at the model for SOA maturity: You go from experimenting to documented procedures, then a level of repeatable processes; once you reach that you're protecting investments in future development and you get true value. Most companies haven't got to that level yet. Few can point to a full set of people, practices, processes and platforms in a repeatable manner.
How does an architectural approach to SOA impact cultural, organizational, operational areas?
Rick Sweeney: The business doesn't own everything anymore. In a traditional IT project, each business unit puts a together a project it wants done. That sponsor controls and owns the entire deliverable, and feels like it owns everything around it. When you move into SOA, you don't own everything -- you leverage new and existing components, so the realm of accountability/ownership expands.
It's a big culture shift. If you move from your own house on your own lot to a condo association, there are some benefits, like your driveway plowed. On the other side, you can't paint your front door pink or add a garage. That's a culture shock, to move from your own property where you can do whatever you want, to a condo where you can't control what's outside.
From the IT side, it's no longer one project. Under an SOA approach, a project gets delivered with one team making enhancements at the channel level, one team building new services, one team in charge of integration; or a channel team might be working on channel enhancements for several channels and the integration team pulls it all together. That's anti-intuitive to how things traditionally have been done.
[Organizationally] the project manager, instead of overseeing one project, now it may be a matrix, so all the integration capability is delivered on time, all channel enhancements, etc. A project is comprised of different components, and the SDLC process needs to change in the way requirements are gathered, how coding is done, and organizationally the resources/skills/roles will change.
[In terms of operations], how we deploy and test these is all changed. Operationally, when you're deploying SOA, the way you have to manage deployment changes as well.
You say SOA architects will have to make the biggest commitment and do most of the work -- can you explain?
Sweeney: The effective adoption of SOA is very complex, and requires a significant amount of changes and transformation. It's something that has to evolve over time. An SOA architect should be most understanding of this complexity, what needs to change and how it needs to change. They need to become facilitators, educators, and in many cases the doers. In traditional enterprise architecture practices they become the ivy tower: "We set the standards; it's not our fault it's not implemented correctly."
With SOA everyone is trying to evolve to something they haven't done before, so you need to help guide them and facilitate it. It takes a big commitment on SOA architects to make that happen. They have to do it at all levels -- communicate the needs for requirements; and know how to guide operations leadership, SMEs, designers, developers, testers, because it's all different. You've got to take them all out of their comfort zone, and guide but also drive. If you leave it up to them and it fails, you've lost your opportunity.
For more information about the SOA Enterprise Architecture Framework (SOA-EAF), see Sweeney's blog.
This was first published in September 2010