By Aaron Tan Dani

Enterprise Architecture in a Nutshell
If you do a search on Google with the question “What is Enterprise Architecture?” you will find many articles telling you that there is no universally agreed-upon definition.

One definition, by IASA, is that it is the art and science of designing and delivering valuable technology strategy for business. IASA is an association for all IT architects which includes those in the fields of infrastructure architecture, business architecture, information architecture and software architecture among others.

A simple definition of course doesn’t give the big picture. For that, it’s probably useful to look at the evolution of Enterprise Architecture. As a discipline, it’s been around for nearly three decades.

History of Enterprise Architecture
Many people point to1987 as the starting point as that is when John Zachman published an article in the IBM Systems Journal which described a framework for information systems architectures.

It’s interesting to note that Zachman later said that he wished he had used the phrase “Enterprise Architecture” instead of “Information Systems Architecture” for the framework because it had less to do with information systems and more with the enterprise.

Actually, the beginnings of what would grow to become known as Enterprise Architecture started nearly two decades earlier, in the late 1960s when Zachman was an account executive in the Marketing Division of IBM. The client he was responsible for was undergoing a huge corporate merger which entailed major integration issues.

Typically, computers back then were used to automate manual processes done by workers. However, when changes are made to an organization, this would often render the automation system obsolete.

Zachman turned to a colleague named Dewey Walker, who was the Director for Architecture for IBM’s Information Systems Control and Planning Group, for advice on handling the integration problems of his big corporate client.

Separating Responsibilities and Processes
Walker’s view was that “organizational responsibilities” and “processes” were two different things. As such, systems should be designed to automate the process, not to encode the organizational responsibilities, to keep these two independent of each other.

Separating these two variables meant that management could change organizational responsibilities without rendering the existing system obsolete. Zachman concluded that creating a structure of independent variables and maintaining visibility into that structure was necessary in order to manage and change it.

Zachman then looked into other fields like buildings, airplanes and locomotives, to see how these things were put together. He soon realized there was something similar in how the design patterns were described in all these industries. He concluded that since architectural design descriptions all used the same categories and patterns, he could also apply that to the enterprise as well. And with that, the Zachman Framework was born.

Methodology Needed
It’s worth noting that the Zachman Framework was designed to describe an enterprise. It didn’t tell you how to do Enterprise Architecture. A methodology was needed for that.

The US Department of Defense tried to create an Enterprise Architecture in 1994 called the Technical Architecture Framework for Information Management (TAFIM). In 1996, the US Congress mandated all federal agencies to take steps to improve the effectiveness of their IT investments.

However the results were patchy and by 1998, TAFIM was retired by the Department of Defense. It was then handed over to The Open Group, which morphed it into what is today known as The Open Group Architectural Framework (TOGAF). 

The need for Enterprise Architecture actually arose from two key factors. Firstly, systems were becoming more and more complex, costing organizations increasing amounts of money. Secondly, these expensive IT systems were often not aligned with business needs, so very little value could be derived from them.

Zachman himself has asserted that Enterprise Architecture is not about building IT models but about solving general management problems. It can be said that it is designed to help to reduce IT complexity and cost, leading to an increase in business value and productivity. Ultimately, it helps to improve an enterprise’s competitiveness in the marketplace.  

In 2008, IASA, an association for all IT Architects, launched The Information Technology Architecture Body of Knowledge (ITABoK).  It is a free public archive of IT architecture best practices, skills and knowledge developed from the experience of individual and corporate member. 

According to Gartner, before 2010, Enterprise Architecture was Framework-driven and then Process-driven. After 2011, it became Business -driven. But since 2014, we have seen the emergence of the Digital-Business- driven EA, which is designed to help enterprises gain competitive advantages by way of digital transformation.

Digital EA is the wave of the future. It enables agile business change and innovation, allowing Enterprise Architects to adopt the additional role of innovator who can recognize, understand and track new digital business technologies to the strategic advantage of their organizations. It is an approach to architecting Digital-Business-driven EA entails four key components: Framework (e.g. Zachman’s Framework, TOGAF), Technology (defined by various technology providers), Skillsets (IASA’s IT Architecture Body of Knowledge) and Notation (e.g. The OpenGroup’s ArchiMate) or in short – FTSN (Framework-Technology-Skillsets-Notation). These components are analogous to a musical orchestra as can be seen in the diagram below.

In a successful orchestra, you need to have a good conductor with a musical score (framework), various musical instruments (technology), skilled musicians (skill) and a universal musical notation that every musician can understand (notation). Similarly, in Enterprise Architecture, we would need to have skilled architects (skill) who can customise the EA framework for their organisations by selecting the right technology and using a common language for the enterprise.   

Aaron Tan Dani
Chairman of EA Chapter, Singapore Computer Society
aarontan@scs.org.sg