Too Many Servers: A Case for Enterprise Architecture and TOGAF 9

Together, EA and TOGAF could provide a pivotal and crucial contribution to the IT profession and society.

'Twas after the second martini (shaken, not stirred) that the truth surfaced from my friend, a professor from a renowned business school. There were "too many servers" in the company. This was at the conclusion of a day-long retreat of business executives and senior IT architects trying to figure out why the company could not make any headway in achieving its goal of creating a unified business model across its 300 related, but distinct,...

lines of business.

I shook my head in disappointment and in deja vu as the import of that statement hit home; three years previous a similar statement by a senior IT architect I knew who worked for a large organization had prompted his executive manager to impose an immediate freeze on all server acquisition, throwing the entire IT portfolio (and company) into disarray.

And now, again, hearing another very senior IT architecture consultant from a well-established company transmitting this same unqualified message to another large client was incredibly discouraging. And, as certainly as fall follows summer, I expected this would probably reap a similar bitter harvest.

I innocently asked whether my friend's business school, which taught IM/IT Management, had ever discussed the use of Enterprise Architecture (EA). He replied, "No, but tell me more." (I was going to anyways.)

Slowly I unveiled the import of EA in general and specifically mentioned the long-awaited EA framework effort from The Open Group, namely TOGAF 9. What really pleased my friend during the course of our discussion was the way that the architecture framework had a business value focus and was closely integrated with the business planning cycle at the strategic, operational, and tactical levels. TOGAF 9 not only works with business capability planning, but is also integrated with internationally recognized frameworks for portfolio/project management, service management, governance, and system development .

Essentially, TOGAF is an architecture design methodology that came out of the cross-organizationally focused information management/IT domains, but is versatile enough to act as a framework for business design. The latest release of TOGAF, Version 9, could be described as a strategic, business-driven methodology that gives chief executives (and industry/stock analysts) visibility into how the corporate vision is to be achieved. Today, IT is an omnipresent enabler in most companies. The redefinition of IT in TOGAF 9 as "the lifecycle management of information and related technology within an organization" changes the emphasis from hardware and software to the secure provision of quality information to authorized stakeholders so that they can make the best possible decisions.

As I explained to my friend, another attractive element of TOGAF 9 is its descriptive (versus an inflexible, template-driven prescriptive) nature that allows it to be adapted for use in any organization in conjunction with existing corporate or industry standards, most of which are model-based (e.g., Zachman EA Framework and its descendants). Also TOGAF 9's versatility as an exhaustive set of best practices, emanating from expensive and painful lessons learned, makes it usable in whole or in part to solve a myriad of problems in either a small start-up company or a global conglomerate. Concepts such as risk management, business transformation readiness, interoperability (at the business, information, and technical levels), stakeholder management, business scenarios, gap analysis, and so on are fundamental to all types of planning at all levels. In short, TOGAF 9 is an ideal methodology to be used globally and taught at the undergraduate and graduate level in both business and technical curricula, creating a common language with which the two solitudes of business and technology can communicate.

As I implored the bartender to give me another olive, my intrigued colleague asked "What is the implication of "open" in The Open Group?" Good question, I thought, as I deftly speared the new entry dropped into the murky depths of my beverage. Actually, I said, the idea of "open" is often applied to things (e.g., standards, software, and hardware) but is seldom applied to processes. This is especially true in the domain of IT, where "silver bullet" EA methodologies are carefully nurtured, promoted, and legally protected. This makes sharing, elaborating on, and integrating the actual (and expensive) work products difficult, be they a gap analysis or a capability maturity model. The "open" also means that it is freely available for all to use, subject to certain conditions . Adherence to an "open" methodology or business process facilitates cooperation between multiple businesses and consultancies working together in any scenario. For example, mergers and acquisitions are notoriously difficult and their numbers are increasing as industries consolidate. EA models and associated processes can provide the corporate "blueprint" for aligning business and IT goals during M&As that helps determine corporate value and assists in the subsequent integration exercise.

"Now, how is this related to too many servers?" my friend interrupted as he tried to figure out whether this entire discussion was an interesting diversion or actually relevant. I swallowed my latest victim and prepared to give a concise response. In fact, there were too many servers; in fact, there was too much infrastructure. The question was how to explain "why?"

Knowing the company well, I proceeded with a tangible example of the way it does business. Each one of the company's three hundred lines of business had its own definition of a "client," making the realization of the corporate goal of integrated client relationship management a nightmare. This situation provided mind-numbing employment for an army of analysts, programmers, database administrators, and assorted technology specialists who were tasked with integrating the company's disparate information and applications -- all of which were on different platforms through a host of undocumented interfaces, by the way. The "heads-down, get on with it" attitude of the company exacerbated the problem. This situation resulted in client data and applications being resident on hundreds of servers, little of which was usable for the crucial marketing or client relationship management functions.

Now, if the company had used Enterprise Architecture and TOGAF 9, they would have taken the corporate direction and designed the enterprise. They would have used architecture to define how to implement the business model and systematically address the company's strategic objectives in a top-down, integrated manner focusing on delivering business value. In this case, the company's "unified" business model would have called for the elaboration of a corporate client relationship function across the three hundred lines of business. This would have resulted in a common definition of "client" that everybody could use, as well as a simpler IT infrastructure containing two orders of magnitude less information. However, this information would be of high quality (i.e., immediately usable) and could be easily leveraged by business intelligence analysts and software (e.g., data mining) to discover crucial bottom-line information such as "buying trends". In this case alone the number of servers, as well as the accompanying legion of support staff, could have been reduced by several hundred and resulted in the creation of significant business value. TOGAF 9 would also have assisted the company in migrating their systems and implementing the architecture from concept into reality.

The symptom is indeed "too many servers." But the root cause is a lack of Enterprise Architecture. Implicitly, that may have been what the Senior IT Architect meant, but explicitly that was not the message communicated to senior management.

At this point my friend reflected and stated that it appeared EA should be part of an overall IT Management course in both business school and the computer science/engineering departments. I deftly agreed and added that TOGAF 9 would be a good place to start looking for course material. I went on to add that The Open Group also has many international case studies and white papers that illustrate the adaptation and use of the readily available methodology.

At this point the bartender plunked another olive in my greatly diminished martini and exclaimed "last call." As I shook hands with my colleague, it seemed to vindicate the five years of Group Architecture Forum creating the new version of TOGAF. Together, EA and TOGAF could provide a pivotal and crucial contribution to the IT profession and society.

 

Robert Weisman has spent more than 25 years in enterprise level planning and implementation for business and IM/IT capabilities, in both private and public sectors in North America, Europe and Australia. For the past five years Bob has been an active member of the Open Group Architecture Forum, a significant contributor to TOGAF 9 and President of the Ottawa/Gatineau Chapter of the Association of Open Group Enterprise Architects (AOGEA). As Principal Consultant and CEO of Build The Vision Inc., he both practices Enterprise Architecture and provides in-house training for Enterprise Architects leading to TOGAF 8 and 9 certification. Robert has an MSc in Computer Science and is a Professional Engineer and Project Management Professional.

 

Dig deeper on BPM Modeling

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close