Manage Learn to apply best practices and optimize your operations.

SOA as a corporate responsibility

David Linthicum discusses how corporations are experiencing inefficiencies with enterprise architectures and the benefits of implementing SOA.

In these days of corporate responsibility and compliance, we need to consider the efficiencies of our IT infrastructure along with other corporate assets. For most companies, enterprise architectures are the single most limiting factor to their business economics since they don't have the ability to adapt to business changes in a timely manner. While many in IT have accepted this as one of life's realities, we could be entering an era where such a reality is unacceptable. Indeed, as innovative corporations learn how to leverage concepts such as SOA to liberate their IT from its currently static and fragile form, less innovative companies will find themselves quickly losing market share to competitors that have embraced the agility value of SOA.

Moreover, the companies who choose to maintain inefficient architectural forms will find that their business value, reflected in their stock price, have suffered as well, perhaps even becoming targets for shareholder lawsuits as the mood shifts around enterprise architecture as a true corporate responsibility. If investors hold management accountable for accounting irregularities and missed sales, then lost dollars around the ineffectiveness of IT can't be far behind. Thus, the ability to maintain effective and agile enterprise architecture is indeed a corporate responsibility, and those who don't focus on their IT architecture could find that they suffer in the short term, and die in the long-term.

While few will disagree that the inefficiencies of existing enterprise architectures have reached a critical level, many individuals depend on "flying under the radar" of those who look at the efficiencies of the company. Let's face it; enterprise architecture looks very technical and is difficult to understand by even technologists, let alone laymen. And so far, IT's invisibility in corporate compliance is reflected in well publicized corporate scandals in the recent years that focused primarily on shady accounting practices and corporate mismanagement, giving IT a pass. If IT is truly the business-enabling resource that we all claim it to be, then there is no way that this can continue to be the case. Today, those who look to value and invest in a company take a critical look at all aspects of the corporation, especially any areas of inefficiencies, including IT. In other words, dysfunctional enterprise architectures could and will devalue the corporation overall, and ! could put the business at risk.

Existing enterprise architectures, however, are not fixable by simply bolting on new technology or building connections between systems. Architecture is a discipline and it requires a great deal of planning and analysis to create a strategy that rejuvenates the enterprise architectures into something that lives up to the corporate expectations of business agility and efficiency. Thus, fixing a brittle, inflexible, and/or vendor-driven architecture could take years, and so now is the time to begin the steps toward creating an architecture that serves the needs of the business rather than the other way around.

How have things gotten this bad?

IT systems, and what many like to think are enterprise architectures, are like archaeology – built in essence on layers upon layers of systems, applications, databases, and connections, typically built or procured to solve a tactical problem. Many corporations talk a good game and brag about the strategic long-term direction of the enterprise architecture that serves the business. The fact is, for most companies, tactical needs have trumped strategic direction over the years. Thus, layers upon layers of technology on top of technology are the end result, and an architecture that is inflexible, static, fragile, and thus difficult to change along with the business requirements. This is the norm, not the exception.

In reaction to this dilemma, enterprises created positions called enterprise architects. These are single individuals or groups within the organization who have the responsibility to drive the enterprise architecture strategy going forward. While a good idea in theory, the reality is that many of these enterprise architects simply don't have the political or budgetary authority within their companies or government agencies to make much of a difference. In many instances, they have been relegated to those who create reports and presentations that few, if anyone, reads, and provide direction and guidance that's easily ignored.

Thus, without good architectural governance and ongoing corporate management pressure to redirect resources to tactical IT projects, the enterprise architectures continue to become more unnecessarily complex, static, and fragile. What was a mere annoyance only a few years ago, is today a clearly limiting factor in the businesses' ability to create shareholder value. The company can't easily shift into new and emerging markets, acquire companies, and adjust major business processes without a great deal of latency. In some cases, they are completely unable to change. In other words, things are bad and getting worse.

The role of SOA

Service-oriented architecture (SOA) is not a miracle cure for bad architecture. However, it is a step in the right direction for those looking to move their existing approaches to enterprise architecture into something more efficient and valuable to the business. Those who embrace SOA as a practical architectural approach in the context of a long-term strategic architectural plan, and are able to execute architectural rejuvenation without tactical interruption, will find that they are quickly ahead of the game.

SOA provides two primary values. First is the ability to reduce redundancy and increase asset value by considering resources as composable, loosely-coupled, and potentially reusable assets. Second is the ability to change IT at a wide range of levels, from the data to function to process to policy to meet continuously changing business needs, even in the face of continuing heterogeneity. As a result, agility is the ultimate value proposition of SOA, and enterprise architecture for that matter.

Unfortunately, as we've written about numerous times before, many looking to leverage the notion of SOA are tempted to sign up for the SOA-in-a-box type of solutions…perhaps an Enterprise Service Bus (ESB), a Business Process engine, or governance tools, or all of the above. Unfortunately, "buying-and-bolting-on" technology solves very little, and could actually make things worse. As ZapThink has said many times, SOA is something you do, not something you buy. But the buying patterns of those in the planning stages of SOA are still very much influenced by "hype-driven" and "manage-by-magazine" solutions that could cause many to find SOA distasteful as they realize the technology does not live up to the hype. There are no quick fixes, and real work must be done.

Indeed, doing SOA is a complex undertaking, and you'll need to learn a great deal to become efficient with the emerging approaches, techniques, technologies, and methods. Those who are successful at SOA plan and design long before they develop and implement. The path to a truly strategic and valuable SOA implementation is something that only comes to those who understand the importance of the work leading up to the technology. In addition, they have corporate sponsorship, the appropriate funding, and the proper amounts of mentoring and training.

The movement toward SOA should be something that has key strategic significance within the company or agency, much like a new product or line of business. In fact, a well planned and implemented SOA will be far more valuable in comparison, considering its long-term ROI. In essence, SOA should have boardroom visibility.

Sometimes it seems that architecture must have a bad PR agency. The value is clear to anyone who analyzes the real cost of the limits that bad enterprise architecture places upon the business. However, the negative effects of IT's limitations on the business are widely accepted and thought of as something that really can't be fixed. Nothing could be further from the truth. If those who manage the company are not motivated to fix their architectural issues themselves, perhaps some highly visible shareholder lawsuits or missed strategic opportunities that cancel the yearly bonuses will become the new motivation. In fact, if you are a shareholder of a company that recently faced significant business impairment, loss, liability, or flexibility issues due to IT's inflexibility (the recent few that come to mind are US Airways, Jet Blue, TD Ameritrade, TJX Corporation, etc) we want to hear from you at rants@zapthink.com. Let's get the bal! l rolling!

The ZapThink take

The inefficiencies that are now systemic to most enterprise architectures clearly limit businesses. Things are only growing worse as the layer upon layer of tactical IT projects pile onto the already dysfunctional existing architectures. Thus, it's no longer a matter of fixing these architectural issues since it's a good thing to do. It's a thing that must be done, unless you plan to put the business at risk. Now is the time to invest in fixing the architecture. This will take years for most organizations, since the problems are so complex and far-reaching. Create a plan and budget now for the rejuvenation of your enterprise architecture, using the best-of-breed approaches and technology, with SOA clearly at the top of the list.

But, jumping feet first into SOA solely as a quick architectural fix is not a good idea either. First, the enterprise needs to agree that there is indeed a problem relating to continuous inflexibility and ability to change, and is willing to allocate resources to solve the problem long-term. Second, organizations need to engage the help they may need, such as SOA mentors, as well as train their staff, obtain the proper advisory. Third, enterprises need to create a long-term roadmap and plan, making sure to consider all of the relevant business drivers, and existing issues. This typically includes multiple projects, moving toward a long-term strategy. Finally, execute effectively, making sure to take the SOA strategy to its logical conclusion, and resist the temptation to redirect resources toward tactical business needs.


Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchAWS

SearchCloudComputing

TheServerSide.com

Close