Seven Things Your SOA Team Shouldn’t Say

Our weather may be cooling down, but the SOA world is really heating up. ZapThink is hearing about this warmth as it meets with enterprise architecture teams at some of the largest companies in the world. At one such meeting, the company in question assembled enterprise architects from all corners of their organization to discuss their roadmap for implementing Service-oriented architecture (SOA). It was the first time in almost six years that this group of about 25 people got together. SOA was the raison d’etre for this latest meeting, a further indication of SOA’s rising temperature. We spent two days going over the technical and organizational challenges that they faced as they considered the move to SOA. By the end of this architecture-fest, they had hammered out some critical action items to help them move forward with their SOA plans.

Before we wrapped up on the second day, they had made concrete decisions about the next steps on their path to SOA adoption — but the best indications of progress were what was actually missing from their discussions. In particular, we specifically commended them on seven things that they hadn’t said — some recurring pitfalls that companies face as they navigate the treacherous road to SOA. By avoiding these seven pitfalls, the company moved their SOA plans forward significantly.

And so, we would like to take this opportunity to share with you what we noticed was absent so that you too can avoid these impediments to your SOA adoption. Here, then, are the seven things you should make sure not to say during your enterprise architecture team meetings:

  1. Let’s get our SOA from our preferred vendor. As ZapThink has explained many times before, you can’t get SOA from software, because SOA consists of best practices. Since architecture is something you do, not something you buy, you must hammer out an architectural plan before selecting software. Many software vendors are positioning their products as the secret sauce for SOA implementation, or even worse, they’re saying that companies should base their entire SOA deployment on their platform. While vendors offer significant elements of functionality, you can’t get the best practices you need to implement architecture properly from any product, no matter how good it is. So, when implementing SOA, decide on architecture first, and the software later.
  2. Where’s the (insert three-letter acronym here)? People love three-letter acronyms — EDA, POA, ROI, SOA, you name it. One of the most over-hyped technology terms du jour, for example, is the Enterprise Service Bus (ESB). No one quite agrees on what it is, but it seems that everyone thinks they need one to make an SOA work. Indeed, the ESB represents a set of capabilities that combine distributed Service intermediaries with reliable message transport. However, many companies are realizing that they already have many such capabilities, and so can implement an ESB using their existing infrastructure. There’s a good chance you already have sufficient middleware — so looking for an ESB (or any other three-letter acronym, for that matter) is often the wrong place to begin. Instead, start with the architecture, determine the best approach to implementing loosely coupled, distributed, composable Services, and only then hammer out the best infrastructure to make that happen.
  3. We don’t talk to the people in that department. One of the most satisfying aspects of our meeting with the large company was that every department from across the company made an appearance. They brought together architects from every corner of their global organization to hammer out their SOA roadmap. When they get to the point of implementing shared Services, the whole organization might not take advantage of all of them, but it’s still critical to have a big-picture view of your enterprise architecture to drive your SOA planning from the top down.By not including networking folks, security experts, application designers, IT specialists, or line-of-business experts in your architectural planning sessions, you are needlessly constraining the value and scope of your SOA efforts.
  4. You’re full of it. SOA introduces technological, organizational, and cultural changes in the way that IT and business work together. Sticking with old approaches simply because that’s the way you used to work will not help you as you move to the Service-oriented way of doing things. For your SOA initiative to be successful, you’ll need to assemble cross-functional, cross-departmental teams. This mixing and matching of different people with different priorities is a recipe for politics, conflict, and even chaos. The best approach to addressing these issues is to take them one step at a time, and the first step is for everyone to be willing to listen to the others on the team and respect and value their opinions. It’s healthy to approach SOA with a dose of skepticism, but never do so without respecting the opinions of the other groups and realizing that SOA will indeed challenge the way you think today.
  5. You do SOA your way, I’ll do it mine. It’s important for companies to distinguish between how you go about doing the architecture, and how you’ll go about using the architecture. Just because different groups might have different ideas for the Services they create and the policies and contracts that define those Services, doesn’t mean that there should be multiple SOA implementations. One of the key benefits to SOA, after all, is that the power of loose coupling provides flexibility to Service consumers, so that the way one department consumes Services need not be the same as the way some other department consumes them. But to get that desired flexibility of implementation, it’s critical to have uniformity of architecture. That’s one of the reasons why it’s so important for companies to bring together company-wide enterprise architecture teams. If architects succumb to the organization’s tendency to silo itself, then the resulting architectures will never live up to the promise of SOA. So, it’s OK to have many different Services, contracts, policies, and processes. But it’s not OK to have different, competing visions for enterprise architecture in the organization.
  6. Let’s consider an alternative to SOA. If there actually were any viable alternatives to SOA, then there would be no problem hearing this in an enterprise architecture meeting, but the fact of the matter is that there really aren’t any other options that companies are seriously considering today. While SOA will certainly evolve over time, it’s important to realize that SOA represents an opportunity to focus on enterprise architecture more so than an excuse to debate some alternative approach. Rather than spending fruitless hours arguing, it’s far better to discuss how to do SOA right and figure out the next steps on your roadmap.
  7. SOA is too hard. Remember the old maxim, “you can do it right, or you can do it over”? Sure, SOA is challenging, but which alternative will truly take more work: figuring out how to get SOA right, or mucking up your architecture so that you (or whoever gets your job after you get the boot) will have to clean up the mess sometime down the road? The fact that SOA is hard is an indication that you’re finally tackling something of value. After all, it’s trivial to buy some new piece of software, but that won’t solve your acute integration and agility problems alone.

The ZapThink Take
Most of the companies we talk to are roughly at the same point in their SOA planning: a lot of Web Services activity scattered across the company, plenty of talk about SOA, a few loosely coupled Services, but little coordination of architectural activities across the enterprise. As such, the simple action of bringing together enterprise architects from across the organization to get everyone on the same page with respect to SOA is itself an important and significant step in moving an SOA implementation forward. Doing so opens up lines of communication, allows different groups to report on their progress, brings everybody up to speed on terminology, and gives the team a chance to learn more from companies like ZapThink about the technical, cultural, and organizational aspects of SOA. One of the most significant purposes that these groups have is to formulate a single SOA story for the team to take to senior management. Developing a single SOA business case and roadmap is a huge win for the company, and groups like these must rise to the challenge.

One of the most important lessons we learned was that a company doesn’t need a formal mandate to get its enterprise architecture act together. Some executive support is vital in order to justify the time spent in the meeting and the travel costs, but once the company establishes the grounds for a business discussion, only the enterprise architecture group can determine the roadmap for how they proceed with their SOA leadership activities across the organization as a virtual team. So, focus on the goal of bringing together your architects from every corner of your organization, and avoid making the mistake of falling into the pitfalls described above. It may sound like a daunting task to bring together all the necessary people required to make SOA a success, but even the largest companies probably have no more than a few dozen enterprise architects with the necessary scope of responsibility to be important additions to your SOA efforts. Find them and bring them together, even for only a couple of days, and you too can be on the road to effective enterprise SOA.