Seven Secrets of SOA'
“There are no secrets better kept than the secrets that everybody guesses,”–George Bernard Shaw
Services continue to be important. And, far from being dead, the principles of SOA–service reuse, a central registry of services, and loose coupling–are more important than ever. We have been in the computing era of Service Oriented Architecture for the better part of the last decade. Everyone thinks they know or understand SOA (is it S‐O‐A or SO‐AH?) and most Fortune 500 or Global 1000 companies have already implemented SOA services. The recent rise of micro services sounds a lot like SOA. In fact, the use of micro services is often referred to as micro service architecture [MSA]. Both architectures are focused on breaking up large monolithic applications into collections of smaller independent services, and both come with the promise of simplifying development. Ironically, the core principles that characterize micro services have been a part of the SOA lexicon for well over a decade. The pressures of cloud, social computing and mobile devices make rapid delivery of projects even more critical.
Why is this type of architecture so compelling? Leading 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:
Increase Business Agility
Reduce Integration Expense
Increase Asset Reuse
Reduce Business Risk and Exposure
With the pace at which society progresses, companies have to do whatever it takes to stay relevant.” The author cites Blockbuster the failed video rental service that once dominated its business, “Think of Blockbuster, they remained the same for years while their competition, namely Netflix, found avenues to quickly move the entire industry forward. Needless to say, it didn't turn out so well for Blockbuster.”
Developing a small set of narrowly‐scoped services and ‘putting them out there ’may be a short-term gratifying exercise, but it will be a long-term night mare
On software and more broadly innovation, Google constantly outflanks its competition and releases new products, some winning, some not, but still is in agile, reducing risk and meeting customer needs. Sounds like what we expect from SOA.
Despite the number of articles and vendor claims on SOA very few have spelled out the specifics of how to be successful. This paper reveals seven (7) secrets to be exact, of how you can quickly be a hero with your SOA initiative. It is based Upon years of experience from many SOA practitioners who deliver services and solutions to major global companies. They have overcome many of the challenges and now share their secrets.
SECRET#1: DON’T BOIL THE OCEAN!
As with anything potentially enormously beneficial, we can get carried away sometimes and try to do too much. Don’t be victimized by hype. 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. Focus on a project that can highlight the clear benefits of SOA, like reworking as mall set of key business processes to improve their flexibility. Clearly identifying a “before services” and “after services” time frame is a good way to get started.
SECRET#2: BEWARE OF‘ABOS’
We have all been victimized by “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 place 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 a small set of narrowly‐scoped services and ‘putting them out there ’may be a short-term gratifying exercise, but it will be a long-term night mare. Get your fundamentals correct–especially focusing on business alignment and flexibility alongside, perhaps the more obvious technical requirements.
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)at your phone, email, door, and other places telling you they can solve all your SOA problems. Don’t believe them. It is important to remember on every important secret: do not wait until your process is right to add the products you need. This is a very logical, but very bad idea. When you decide on the small pond (versus ocean) project, you will need process and technology together. These aspects of a successful SOA are not serial, they are interactive.
SECRET#4: BIG TENT APPROACH
Not all “services” are “web services.” SOA does not need to be based on web services. SOA is an architectural concept. Web services is a realization of SOA, that leverages XML and common Internet protocols (such as HTTP) to deploy (typically) coarse-grained, discoverable services. In theory, you could just as easily build an SOA using something other than web services. Though it'd be difficult to get the requisite degree of decoupling without web Services.
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 is crucial that you are able to manage all services.
Don’t let the endless chatter about standards slow you down. Remember the heyday of web services, when we were always just one specification away from perfect inter operability? Ultimately, that towering stack of protocols collapsed under its own weight. The traditional four standards were identified as XML, SOAP, WSDL, UDDI and unfortunately many, many others. SOAP and XML generally are ridiculously verbose protocols that began with a commitment to simplicity and gave way to mind-numbing levels of complexity. SOAP has given way to REST and XML to JSON implementations
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 are written! Or, even worse, they give into the temptation to create and deploy services without considering the necessary management issues. Don’t let that happen to you—I you get out the map and plan your service route properly you are likely to reach Your SOA destination. Specifically, for a development issue, quality must be designed in to the product, not inspected into it.
SECRET#7: BE A CARPENTER (MEASURE TWICE CUT ONCE-HEY HOW ABOUT JUST MAKING SURE YOU MEASURE
Key to any part of the SOA success story is measuring. All your tools need to provide evidence of measurable value. The most important key to your services is governance. Who is producing these services? How many are there? Where?
Who is consuming them? For what? Can they understand what those services are supposed to do?