Microservices Expo Authors: Liz McMillan, Pat Romanski, Carmen Gonzalez, Elizabeth White, Jason Bloomberg

Related Topics: Microservices Expo, Industrial IoT

Microservices Expo: Article

The Seven Secrets of SOA Success

How not to be misled

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.

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.

More Stories By Greg Coticchia

As CEO of LogicLibrary, Greg Coticchia provides overall direction for the company. He brings to this role 20 years of experience at high technology start-ups, including executive leadership roles in strategic planning, marketing, business development, sales and general management. Greg holds an MBA from the University of Pittsburgh, Katz School of Business, and a bachelor’s degree in industrial engineering from the University of Pittsburgh. He also completed Carnegie Mellon University's Entrepreneurial Management Program.

Comments (6)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Microservices Articles
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is foundational - something customers routinely cite as a top pain point. In his session at @DevOpsSummit at 21st Cloud Expo, Bill Borsari, Head of Systems Engineering at Datera, explored how organizations can reap the bene...
"NetApp's vision is how we help organizations manage data - delivering the right data in the right place, in the right time, to the people who need it, and doing it agnostic to what the platform is," explained Josh Atwell, Developer Advocate for NetApp, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, discussed how to use Kubernetes to set up a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace. H...
Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, will discuss why containers should be paired with new architectural practices such as microservices ra...
In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging and seamlessly coordinating both IT and developer needs for component orchestration across disparate clouds – an increasingly important requirement at today’s multi-cloud enterprise.
The Software Defined Data Center (SDDC), which enables organizations to seamlessly run in a hybrid cloud model (public + private cloud), is here to stay. IDC estimates that the software-defined networking market will be valued at $3.7 billion by 2016. Security is a key component and benefit of the SDDC, and offers an opportunity to build security 'from the ground up' and weave it into the environment from day one. In his session at 16th Cloud Expo, Reuven Harrison, CTO and Co-Founder of Tufin, ...
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In their Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, and Mark Lav...
Many organizations are now looking to DevOps maturity models to gauge their DevOps adoption and compare their maturity to their peers. However, as enterprise organizations rush to adopt DevOps, moving past experimentation to embrace it at scale, they are in danger of falling into the trap that they have fallen into time and time again. Unfortunately, we've seen this movie before, and we know how it ends: badly.
TCP (Transmission Control Protocol) is a common and reliable transmission protocol on the Internet. TCP was introduced in the 70s by Stanford University for US Defense to establish connectivity between distributed systems to maintain a backup of defense information. At the time, TCP was introduced to communicate amongst a selected set of devices for a smaller dataset over shorter distances. As the Internet evolved, however, the number of applications and users, and the types of data accessed and...