There's no doubt that the computing era of Service Oriented Architecture is upon us. Everyone has caught SOA fever (is it S-O-A or SO-AH?) and most Fortune 500s are considering or have already implemented their first set of services.

Why is SOA so compelling? Zapthink, one of the industry's experts on SOA, suggests the following reasons for folks to be enamored with SOA and why it's worth all of the hype:

1. Increased Business Agility
2. Reduced Integration Expense
3. Increased Asset Reuse
4. Reduced Business Risk and Exposure

Pretty compelling and timely. In a recent BusinessWeek cover story entitled "Is Your Company Fast Enough" (www.businessweek.com/magazine/content/06_13/b3977001.htm) the author, Steve Hamm, makes the point that "Speed doesn't kill but is indeed the ultimate competitive advantage, especially with loosely coupled businesses connected on a global level being the basis for progressive business models." On the podcast for this article, the author cites Microsoft and Vista, the next version of Windows, as an example of not being fast. Vista has taken five years to get to market and has just been delayed again. In contrast, BusinessWeek points out that Google constantly outflanks Microsoft and releases new products, some winning, some not, but still agile, risk-reducing, and meeting customer needs. Sounds like what we expect from SOA.

Despite the number of articles and vendor claims about SOA few have spelled out the specifics of how to be successful. This article will reveals the seven secrets to being a hero with your SOA initiative. It's based on LogicLibrary's five years of experience in delivering services and solutions to major global companies. Along with our customers, we've overcome many of the challenges and now we'll share them with you.

Secret #1:
Don't Boil the Ocean
As with anything new, exciting, or potentially enormously beneficial, we can get carried away. Remember the client/server hype? Everything still isn't Internet-based, and those mainframe applications are running just fine. So be selective. Don't start with a massive project that involves a cast of thousands. Think big but start with a small project. Begin with a project that involves buy-in from three camps: an architecture representative, a development leader, and someone who represents the business (could be in the IT management food chain or actual line of business, doesn't matter). Focus on a project that can highlight the clear benefits of SOA like reworking a small set of key business processes to improve their flexibility. Clearly identifying a "before SOA" and "after SOA" time frame is a good way to get started.

Secret #2:
Beware of 'ABOS'
We've all been victims of spaghetti code. The SOA equivalent is "A Bunch Of Services" or ABOS. You can end up with ABOS if you don't align your business needs with your technical capabilities and understand where you can put your services, who will own them, who will use them, etc. In short, know what you have so you can move ahead. It's the basics of good governance. Developing 10 or 20 narrowly scoped services and putting them out there may be a gratifying short-term exercise, but it will be a long-term nightmare. Get your fundamentals correct - especially focusing on business alignment and flexibility alongside, perhaps, the more obvious technical requirements. Make sure you have a design-time repository/registry technology in place (not a spreadsheet or database, please) and make sure it can scale to your needs (you don't want to get a nice department-level product only to re-decide later). But simply putting your services (also known as software development assets and artifacts) somewhere you can find them isn't enough. You have to be able to understand, observe, and guide those who are producing services along with those who are consuming them. Make sure you establish an architecture and design-time governance process that can provide this kind of guidance and that can also produce measurable results, one that goes beyond just allowing you to locate your assets and artifacts.

Secret #3:
It's Not a Process Or a Product;
It's a Process And a Product
Speaking of vendors, there are thousands (if not more) on your phone, in your e-mail and at your door telling you they can solve all your SOA problems. Don't believe them. It's important to remember one important secret: Don't wait until your process is right to add the products you need. It's logical, but a bad idea. When you decide on the small pond (versus ocean) project, you'll need process and technology together. These aspects of a successful SOA aren't serial they're interactive. Getting the process "right" (which will never happen) without a set of initial products you deploy to support and enable the process is as bad as buying products without having analyzed the services and process methodology changes you'll have to make. So get in the pond, select your methodology (with a service provider to help), and get the initial set of tools needed to create the foundation.

What are these tools? Many of the same ones your development teams are using today such as IDEs, SCM systems, defect-tracking systems, requirements management systems, and test automation systems. But there's one other key product you probably don't have in your portfolio - a design-time repository/registry that both binds all these tools together and serves as the communications and governance bridge across all service production and consumption activities. Many folks don't get this right. They wait and wait and wait for the perfect process, and six to 12 months later they're still "studying" what to do, or waiting to perfect their process. By then most products could never reflect their process, and all their developers have "developed" a new set of bad habits - remember, you get one chance to set the ground rules for SOA; after that first project, behaviors become ingrained. So, it's a service and product together. That's the ticket.

Secret #4:
Big Tent Approach
Not all "services" are Web Services. Forrester SOA analyst Randy Heffner did a study of companies using SOA and found that "While most participants were either doing Web Services or planning for them, one firm - a firm that had a major implementation of services - had yet to build its first Web Service. Instead, services were accessed via IBM's WebSphere MQ (nŽe MQSeries)." Another participant had an advanced service invocation framework and the core service access mechanism was JMS. Another firm started doing services with the immediate goal of connecting to business partners, so Web Services played a part in its first service implementation. The lesson is this: Service orientation provides great value with or without Web Services, while Web Services provide a universal accessibility layer on top of a service-based design. Pursue the two as separate but related initiatives. As you plan and build out your SOA it's crucial that you're able to manage all services.

Secret #5:
Standards Shmandards
Don't let the endless chatter about standards slow you down. Let's start with the Web Services standards bodies. There are four! And the standards? Well, the current alphabet soup of Web Service standards (what if we named a standard and no one used it) includes XML, SOAP, WSDL, UDDI, and at least nine others published and promoted. Sure you need to take security, payload structure, and all of those technical issues seriously, but if you wait for all the WS-* standards to sort themselves out you'll be waiting a long time. The real secret here is that most folks today use two: XML and SOAP - your technology stack of choice will help you out with the rest (and if they're worth their salt, will help you migrate your implementations once all those WS-* standards settle down).

And how about UDDI? This standard, which was originally specified as a runtime registry, has become commoditized (Open Source UDDI is readily available and many vendors offer UDDI for free) and seems to be moving from runtime to design time in an attempt to add value. But keep in mind, as we mentioned before, that not all services are Web Services. If you chose a UDDI "standard" (and all of its "user friendly" concepts like models, category bags, and the like) to help your design-time efforts you'll only be focused on Web Services. That's not enough - you have to be able to manage ALL your services. So don't get wrapped around the standards axle. DCE anyone?

Secret #6:
Repeat After Me, "Design Comes Before Production"
We all know that you should design and develop something prior to running it in production. This has never been more important than in an SOA environment. But what often happens is that organizations are stymied by concerns about the performance of new loosely coupled services, even before they're written! Or, even worse, they give in to the temptation to create and deploy services without considering the management issues. Don't let this happen to you - if you get out the map and plan your service route properly you're likely to reach your SOA destination. Specifically for a development issue, quality must be designed into the product, not inspected into it.

Deciding which tools you'll need is one of the first issues to be addressed. A performance monitor, while valuable, isn't at the top of the list. The best place to start is with your current design and development tools, services vendors, and of course your own practices. Get those in shape, do a gap analysis, and see what's missing for your pond project. But start on the design/development part of the equation (and don't forget architecture on the design side of the equation). Get that right and the rest will be much easier. Just like the application itself.

Secret #7:
Be a Carpenter (Measure Twice Cut Once - Hey, How About Just Making Sure You Measure)
Key to any part of SOA success is measuring. All your tools have to provide evidence of measurable value. The most important key to your services is governance. Who's producing these services? How many are there? Where? Who's consuming them? For what? Can they understand what those services are supposed to do? As you can tell by answering these questions, you only need a handful of services before these concerns arise. Get control of them before they get control of you. Even 12 or less services could be a potential disaster without the right design-time SOA governance process (and supporting tools) in place.

Summary
As with any effort in new technology the pioneers that went first ended up with a few "learning" arrows in their backs. SOA is now past the pioneering stage, enough so that we can be clear about the secrets of a successful SOA. By using these seven secrets you can avoid the arrows and reap the rewards of a properly designed and executed SOA.