10 Tips for Getting Started with Service-Oriented Architecture - Tips 3 through 6
( Page 2 of 3 )



3. Function-first, not product first.
Both Schmelzer and Heffner emphatically agree that one of the easiest ways to kill your SOA hopes is to approach your design phase backwards.

“People are doing it so backwards, they are saying, oh I need SOA, so then let me buy an EMC solution, oh and then let me figure out what services to build and then let me figure out what architecture I need,” Schmelzer said. “Before you even build your services, think about how the services are going to be used, because you can create a service any of two hundred different ways.”

Heffner echoes Schmelzer: “In terms of designing your SOA platform, do it function-first, not product-first,.  Because by examining the functions you'll need, then you can better map those to what capabilities you'll have in your existing products and what you can get in any new products. Start with that.”

Resource Library:

4. Don’t try to make everything service-oriented.
Not every  application in the enterprise is suited to a service-oriented architecture, so don’t try to shoe-horn it into everything, Schmelzer says.

“If you apply SOA where things don't change, then all you are doing is introducing variability and inefficiency into the process for no good reason,” he said.

For example, it wouldn’t make sense for an organization to convert a wire transfer process to SOA because it is not going to change and you wouldn’t want to introduce variability into the process, Schmelzer said. In that case, it makes sense to just leave wire transfers as its own service. Schmelzer explains that functions need to be examined first for SOA suitability—another reason to adhere closely to tip number three before delving into an SOA project.

“Ask yourself, is this process going to change? And when it changes, does it cost me a lot in terms of money and complexity?,” Schmelzer said. “If the answer is yes, then that could be service oriented.”

5. Incremental SOA is a good thing.
Organizations who approach SOA incrementally set themselves up for greater successes than those who chose complex, unwieldy implementations with a lot of long-term returns but very few short-term gains.

“Maybe you want everything in your organization that can be service-oriented to be service-oriented , but that doesn't necessarily mean you should do it all at once,” Schmelzer said, “in fact you probably shouldn't because one of the great things about starting small is that the penalty of failure is so low."

It makes more sense to do small, bite-sized projects. It is easier to create miniature business case scenarios for these short projects and their success guarantees future projects.

“Focus on what your immediate needs are for the SOA based solutions you are going to deliver in the near term,” Heffner said. “Because, if you don't deliver in the short term, you won't deliver in the long term because you won’t get the funding for it.” 
6. Think about how near-term returns complement long-term goals.
As you are doing these smaller projects, it is important to think about how they funnel into your long-term SOA goals, of course.

“Put those immediate requirements in the context of your longer-term SOA platform goals so that you can  best balance of near term and long term concerns,” Heffner said. “And also try to find something that you can do and pay for within the current delivery project, because very few people get big buckets of infrastructure money to go on a shopping spree and have fun buying all sorts of new SOA platform products.” 

>>> More Web Services/SOA Articles          >>> More By Ericka Chickowski