>Lessons from Mainframes and Enterprise Architecture

>

As many organizations have transitioned from a mainframe computing to a more distributed platform, they have become more decentralized and in many cases more lax in terms of managing changes, utilization rates, assuring availability, and standardization.

However, management best practices from the mainframe environment are now being applied to distributed computing,

DM Review, 21 March 2002, reports that “people from the two previously separate cultures—mainframe and distributed [systems]—are coming together to architect, develop, and manage the resulting unified infrastructure.”

  1. Virtualization—“Developers of distributed applications can learn from the approach mainframe developers use to build applications that operate effectively in virtualized environments…[such that] operating systems and applications bounce from one server to another as workload change” i.e. effective load balancing. This improves on distributed applications that “have traditionally been designed to run on dedicated servers” resulting in data centers with thousands of servers running at low utilizations rates, consuming lots of power, and having generally low return on investment.
  2. Clustering—“A computer cluster is a group of loosely coupled computers that work together closely so that in many respects they can be viewed as though they are a single computer [like a mainframe]…Clusters are usually deployed to improve performance and/or availability over that provided by a single computer, while typically being much more cost-effective than single computers of comparable speed or availability” (Wikipedia) The strategy here is to “reduce the number of servers you need with virtualization, while providing scaling and redundancy with clustering.”
  3. Standardization—Distributed computing has traditionally been known for freedom of choice marked by “diversity of hardware, operating platforms, application programming languages, databases, and packaged applications—and an IT infrastructure that is complex to manage and maintain. It takes multiple skill sets to manage and support the diverse application stack…standardization can help you get a handle on [this].

Thus, while we evolve the IT architecture from mainframe to distributed computing, the change in architecture are not so much revolutionary as it is evolutionary. The lessons of mainframe computing that protected our data, ensured efficient utilization and redundancy, and made for a cost-effective IT infrastructure do not have to be lost in a distributed environment. In fact, as architects, we need to ensure the best of both worlds.

>Simplification and Enterprise Architecture

>

Enterprise architecture seeks to simplify organizational complexity through both business processes reengineering and technology enablement. Technology itself is simplified through standardization, consolidation, interoperability, integration, modernization, and component reuse.

Harvard Business Review, December 2007, reports on simplifying the enterprise.

Large organizations are by nature complex, but over the years circumstances have conspired to add layer upon layer of complexity to how businesses are structured and managed. Well-intentioned responses to new business challenges—globalization, emerging technologies, and regulations…–have left us with companies that are increasingly ungovernable, unwieldy, and underperforming. In many more energy is devoted to navigating the labyrinth than to achieving results.”

Having worked for a few large organizations myself, I can “feel the pain.” Getting up to 8 levels of signature approval on routine management matters is just one such pain point.

What causes complexity?

Complexity is the cumulative byproduct or organizational changes, big and small that over the years weave complications (often invisibly) into the ways that work is done.

What is sort of comical here is that the many change management and quality processes that are put in place or attempted may actually do more harm than good, by making changes at the fringes—rather than true simplification and process reengineering at the core of the enterprise.

Here is a checklist for cutting complexity out of your organization:

  • “Make simplification a goal, not a virtue—include simplicity…[in] the organization’s strategy; set targets for reducing complexity; create performance incentives that reward simplicity.
  • Simplify organizational structure—reduce levels and layers…consolidate similar functions.
  • Prune and simplify products and services—employ product portfolio strategy; eliminate, phase out, or sell low-value products; counter feature creep.
  • Discipline business and governance processes—create well-defined decision structures (councils and committees); streamline operating processes (planning, budgeting, and so on).
  • Simplify personal patterns—counter communication overload; manage meeting time; facilitate collaboration across organizational boundaries.”

Leading enterprise architecture and IT governance for a number of enterprises has shown me that these initiatives must be focused on the end-user and on simplifying process and improving results, rather than creating more unnecessary complexity. The chief architect needs to carefully balance the need for meaningful planning, helpful reviews, and solid documentation and an information repository with simplifying, streamlining, consolidating, reengineering, and facilitating an agile, nimble, and innovative culture.

>Microsoft and Enterprise Architecture

>Microsoft—with 79,000 employees in 102 countries and global annual revenue of $51.12 billion as of 2007—is the company every consumer loves and hates.

On one hand, Microsoft’s products have transformed the way we use the computer (yeah, I know Apple got there first, but it’s the Microsoft products that we actually use day-to-day). Everything from the Microsoft operating system, office suite, web browser, media player, and so on has made computers understandable, and useable by millions, if not billions of people around the world. The positive impact (excluding the security flaws and pricing) has drastically made our lives better!

On the other hand, Microsoft is a “near-monopoly” with estimated 90%+ market share for Office and Windows O/S. Near-monopolies, like Microsoft are feared to stifle competition, reduce innovation and consumer choice, and drive up prices.

Microsoft has been convicted by the European Commission of having “improperly bundled a media player with its Windows operating system and denied competitors information needed to make their computers work with Microsoft software…fines and penalties could reach…$2.77 billion. “EU officials praised the decision…for protecting consumers.” While “Microsoft backers said, the ruling will stifle innovation by making it tougher to design products with new features.” Additionally, “the EU is reviewing complaints about Microsoft’s Office Software and concerns over how Microsoft bundled encryption and other features in its new Vista operating system.” (Wall Street Journal, 18 September 2007)

From a User-centric EA perspective, there is a similar love-hate relationship with Microsoft. As architects, we believe and preach standardization, consolidation, interoperability, and integration—all things that Microsoft’s array of products help us achieve ‘relatively’ easily (imagine, if instead of an integrated Office Suite, as well as mail, calendar, task list, and underlying operating system, we had to use an array of non-integrated products-yikes!). However, also as architects, we look to be able acquire innovative technology solutions for our organizations that will help us achieve superior mission performance, and to acquire products at prices that produce the best value for the enterprise—to achieve that we need a marketplace based on healthy competition that drives innovation and price competition.

So we love and need Microsoft, but we fear and loathe the ramifications of such market dominance.