30 Years of Enterprise Architecture and it still has a long journey ahead

Mark Carr, Chief Architect, The Hong Kong Jockey Club

Mark Carr, Chief Architect, The Hong Kong Jockey Club

Earlier this year I had the great privilege to share a stage with John Zachman. During our discussions, we talked about the history and future of Enterprise Architecture, both agreeing that the practice has come a long way, but it has a far more difficult journey ahead.

The initial Architecture framework, named A Framework for Information Systems Architecture, by John Zachman, was published in1987 in the IBM Systems Journal. The Zachman Framework for Enterprise Architecture came later, a 1990extension to the original.

In 1996, The United States Of America Federal Government passed the "Information Technology Management Reform Act" (later renamed "Clinger-Cohen Act" after its co-sponsors, Rep. William Clinger, R-PA., and Senator William Cohen, R-ME.). This act established the role of Chief Information Officer and aimed to improve the acquisition and management of information resources, by:

• focusing information resource planning to support strategic missions;

• implementing a capital planning and investment control process that links to budget formulation and execution; and

• Re-thinking and restructuring the work required before investing in information systems.

The Federal Act directed the development and maintenance of the first formal Information Technology Architectures (ITAs), to maximize the benefits of information technology (IT) within the Government and encompassed the first three columns of John Zachman’s framework.

In September 1998, I joined an IT consultancy organisation heavily involved in US Federal Government contracts; by implication, the organisation required its Architects to be compliant with the legislation. I received my first Architectural title (Technical Architect) and was trained in the POLDAT framework (POLDAT representing “domains of change” within the framework, namely: People, Organisation, Location, Data, Applications and Technology).

Being confined to a single domain within the domains of change indicated I was in-fact, an engineer. Most of my initial engagements concentrated on design and build of infrastructure.

While project delivery is a fast-moving, goal orientated process; transformational Architecture is a multi-year endeavour of managed evolution.

Identification of any Application Architects, to enable solution validation, failed. At the time, Application Architects were still coders who demanded “the biggest box,” “largest storage” and “fastest networks.” Many times I experienced system performance issues and was directed to upgrade memory or install a faster processor, just to find the issue was sloppy code. My frustration was further enforced when requested to participate in recruitment events; candidates would position themselves as “Microsoft Architects”; “ServerArchitects” or, my personal favourite, “CPU Architect.” Attempts to engage in a more architectural conversation would generally fail, as the candidates would revert to their comfort zone. The architecture was indeed an engineering activity.

In the intervening years the role Enterprise Architect has emerged, a role which elevates its incumbent to look across domains and provide a strategic view to attain the Enterprise goals of an organization. A helicopter or some say, a satellite view, but with the perception that this has no real understanding of the needs of the now. This is the great challenge; Enterprise Architecture still has a long way to go. Bridging the gap between Enterprise Architecture, Business immediate need; Project Delivery and Financial Control is a difficult act.

Architecture has come a long way since its inception in 1987; it is still seen as an IT-specific competency, not fully understood by the business community. However, for Architecture to realize its full potential it needs to mature even further and promote the role of Business and Information Architects; positioning these as trusted advisors to the c-Level community. Once established, true strategic plans can be created that can provide strategic innovation, rather than point based solution design.

The starting point is a documented, valued, executable, syndicated, and endorsed (at least the CIO, but preferably the CEO) Reference or Target Architecture. As the Architecture documentation is targeted at C-level stakeholders, it should be easily understandable and free of technical jargon. The Architecture documentation must clearly articulate the business goals and the Enterprise vision, policies, standards, and directives to support these goals. This will enable the strategic road-map creation and form the basis for a strong governance process.

While project delivery is a fast-moving, goal orientated process; transformational Architecture is a multi-year endeavour of managed evolution. Managed evolution can be conceptualised as the realization of Nudge Theory; Richard Thaler’s 2017 Nobel Economics Prize winner in the field of behavioural economics. The concept of nudge theory is a relatively subtle policy shift that encourages people to make decisions that are in their broad self-interest. It’s not about penalising people financially if they don’t act in certain way. It’s about making it easier for them to make a certain decision. “By knowing how people think, we can make it easier for them to choose what is best for them, their families and society,” wrote Richard Thaler and Cass Sunstein in their book Nudge, published in 2008. Therefore an Architect has to be a master of persuasion and influence.

Only a few organisations have moved forward with the approach of instilling Architecture in the strategic planning phase. The transition from IT to enterprise will be a long and winding road. Who knows, in the next 30 years Architecture may achieve what John Zachman set in motion 30 years ago.