SOA From a Management Perspective: Part Two

This is Part Two of a two-part note. Part One provides a basic understanding of SOA, the rollout plans for major software vendors, and the benefits of SOA.

Concerns About SOA

Back in the day when procedures and subroutines were all the rage, there was a performance concern: Did the use of subroutines, with all of its branching back and forth and passing of data, degrade performance as opposed to duplicating the code in stream? The same concern with message traffic in service-oriented architecture (SOA) is being voiced by some information technology (IT) shops. Vendors downplay this concern, explaining that today's processing speeds more than compensate for service calls and use of generalized routines. The problem is that you need to compare apples with apples. Improved processor speeds will benefit both SOA and non-SOA environments. Assurances must be made that the time it takes to process a complete transaction in an SOA environment is not significantly slower than what companies are experiencing today. This is why previously mentioned performance alerts are critical to the success of SOA.

The prevailing IT culture may inhibit SOA. Traditionally, IT shops are measured by the lines of code generated. This is contrary to the reusability benefit of SOA. The paradigm needs to be shifted to reward rapid and agile implementations rather than the size and complexity of the programs.

The cost of implementing SOA will not be cheap. In addition to reengineering your existing architecture technology, SOA will require a significant investment in human capital so that business analysts can define finite business processes; systems analysts can convert these processes into specifications; and systems engineers and programmers can translate everything into functional and manageable services.

Lacking at this stage of its deployment, but quickly catching up, are third-party tools to assist in the monitoring and improving of performance in an SOA-defined environment. Early adopters of SOA must either construct their own resources or work jointly with vendors to test beta versions of tools. This is why, for example, pioneering companies are using everything from Excel spreadsheets to simple databases as repositories for services. By using in-house tools, companies have the opportunity to survey the technology landscape for the best solution for their infrastructure.

Although there are differing opinions on the subject, many consider Web services as a mandatory element of SOA. For those sharing this viewpoint, Web services must be implemented properly to create a solid SOA environment. While some companies may be taking a wait-and-see approach, now would be a good time to get your Web services house in order.

As SOA implementations start to proliferate across an enterprise, traditional, manual governance solutions, which include design walk-thru's, conference room pilots, and after-the-fact reporting, may be inadequate. Consequently, elements of the system life cycle approach will need to be reviewed to incorporate a more proactive governance strategy. Staid thinking that your application lifecycle has served your organization well for many years may result in missing the SOA mark and achieving its expected benefits.

How Can You Get to SOA?

Now you're excited about SOA. You have bought into the benefits and can't wait to get started. Not so fast!

SOA is a tough sell to company executives. SOA helps your company be more flexible and agile. However, it is difficult to make a business case or develop cost savings based on flexibility and agility. Except in the rare cases where responsiveness can mean the winning or losing market share, justification for a change in technology is built on solving business problems or gaining a competitive advantage. Remember that Y2K brought about major systems upgrades not because of a more effective use of technology, but rather due to its threat of shutting down businesses.

As has been stated above, service reusability is a major drawing point of SOA. Making this concept a reality is easier said than done. We were unable to do it for objects and we couldn't make it happen for components. What makes us think that SOA will be any different? Oh, yea—corporate governance will do the trick. Even if corporate governance could enforce SOA policy, we are adding another layer of management and probably staff. Great—now we are responsible for increased labor expenses and overhead.

SOA can be explained as enterprise computing, reusable services, and a faster construction methodology. While SOA may be a straightforward, understandable concept, it requires a steep learning curve for companies wanting to embrace this technology and reap the expected benefits. Traditional developers, who take the big picture approach toward application integration, will need to break flows and processes into smaller bites if reusability is to flourish. Developing a core group of IT professionals to spearhead the effort will not only limit your exposure to minor setbacks, but will also create a cadre of SOA disciples to spread the word.

Another paradigm that needs to be shifted is the traditional image of the IT professional. The image of a "bits-and-bytes" hermit that lives somewhere in a technology cave and speaks in three letter acronyms won't cut it. If IT professionals are to effectively work side by side with their business counterparts to model finite processes, both groups must speak a common language. This language must be in the tongue of the end user. While you may say that your company has already overcome this hurdle, try corroborating this with the user community. Surely enterprise service buses (ESBs), repositories, and directories are important to the eventual success of SOA; they need not concern the user and will only muddy the water.

But the million dollar question is, "How do we implement SOA?" Some vendors would suggest a gradual deployment. But this is tantamount to straddling a boat with one foot on the boat (the SOA environment) and other on dry land (the current software infrastructure). As the boat drifts further and further away, your resources are stretched to their limits. You fall in, and your current and future states start to flounder. While this can be done, you had better be a good swimmer and have someone on staff proficient in CPR—that is, core program resuscitation.

Depending on the age of your existing applications, internal and external programming interfaces may be difficult to find with a single program, much less than in an enterprise's entire application library. To use a service, the current interfaces must be ripped out or neutralized. Think about it. Take the credit checking/updating service, for example. This could be used in standard order taking, returns processing, quote generation, onetime orders, promotional sales, discounts taken, and who knows where else. Now go through each of these programs or modules, trace the interface logic, and determine what changes have to be made. Not an easy task. While you may have access to the source code, you may not have the technical resources to play this game of technical hide'n'seek. While the software vendor can offer assistance, can you afford it?

While we are talking about technical resources, to take advantage of SOA's agility, the services may have to be modified or, dare we say, enhanced. Again, unless you have the technical resources to perform this type of modification, you may be at the mercy of the software vendor. If you argue the agility case for SOA, make sure that your company can support it or, at least, pay for it.

Unfortunately, SOA may be Y2KAOA—that is, Y2K All Over Again. SOA is not a case of migration; it is a case of rip out and tear down to the technology foundation, and replace on an enterprise-wide basis. While large enterprises may have the luxury of choices, small and medium enterprises (SMEs) certainly do not. To use an analogy, SOA is similar to the era when automatic transmission was first offered in cars. It made driving easier and less stressful. But you probably did not take your stick shift car to your local mechanic and have the manual transmission replaced. While your current car may not have been the latest and greatest in automotive technology, it was functional and served a valuable purpose. Similarly, your current enterprise software is most likely fulfilling its stated mission. Just because new technology is being touted by software vendors does not mean you are going to scrap what you have. No, you are going to wait until you can establish a business case for replacing the software such as faster processing to keep up with increased orders; better pricing algorithms reflective of your company's practices; or improved tools for financial analysis and decision-making. When you can make the business case, you will want to determine what software solutions are built on the SOA technology and incorporate this advantage into your evaluation and selection.

Summary

Some of you may be saying, "Can't this author make up his mind? Is he in favor of SOA or not?" As we have seen, there is little doubt that SOA could offer real, tangible benefits in terms of reusable services and faster application deployment. Whether we can achieve these benefits this time around remains to be seen. Regardless, SOA is not a technology that can be implemented in an incremental or piecemeal fashion. You can't just get your big toe wet; it requires a complete submersion. When you can make a convincing argument to your management to upgrade your enterprise portfolio, SOA may be mature enough to be considered a reasonable alternative. Right now chief information officers (CIOs) would best be served by watching from the sidelines and tracking the SOA developments while keeping their management informed. Like the first year model of a new car line, it can be unwise to implement the first version of software using SOA. Finally, what is particularly interesting is that few vendors are even offering an SOA-based solution, yet we are already talking about SOA 2.0 and advanced SOA.

About the Author

Joseph J. Strub has extensive experience as a senior project manager and consultant for the planning and execution of enterprise resource planning (ERP) projects for manufacturing and distribution systems, for large to medium companies in the retail, food and beverage, chemical, and consumer-packaged goods (CPG) process industries. He has developed marketing and communication programs for IT organizations and consulted on off-shore, outsourcing opportunities for multinational companies. Additionally, Strub was a consultant and information systems auditor with PricewaterhouseCoopers, and an applications development and support manager for several Fortune 100 companies. Currently, Strub is an independent consultant.

He can be contacted at JoeStrub@WriteTechnologyPlus.com.