Enterprise Architecture (EA) units can be found in most major enterprises today. This is encouraging for a relatively new field which was only formally recognized in the 1980s. Indeed, there is now a widespread recognition that EA is a very important undertaking that can have far-reaching benefits for the organizations that embrace it.

This promise of EA, however, all too often clashes with a different reality when we examine just what EA units are doing in enterprises. Some of these units are simply “product pickers” who select technology for their IT departments. Perhaps that is a little harsh, since managing the technology portfolio is certainly necessary and arguably a core function of EA. But if technology selection is the only thing an EA unit does, then it is falling far short of the acknowledged goals of the overall discipline of EA.

In other organizations, EA units can be found that are theoretical “talking shops” staffed by individuals who constantly refer to EA theory and the inevitable arguments that exist within any body of theory that is still being worked out. Again, this judgment may be overly harsh, since theory is vital. Without theory, we do not know why we are doing, what we are doing, or what we should be doing. Yet, an almost total focus on theory blinds EA practitioners to the urgent and practical needs of the enterprises they work for. Such enterprises do not need EA to spend its time trying to optimize the way that EA works—they want EA to deliver something useful.

Another failing of EA units is an overly tight coupling with Information Technology (IT) organizations. Today, attitudes to IT in most large enterprises are increasingly negative. Fairly or unfairly, IT is seen as an expensive, self-referential, and incompetent cost center. Fifty plus years of organic growth in IT infrastructures have created increasingly unmanageable information management environments that now threaten the possibility of business change. This is one of the core problems that EA must solve, but it cannot be done if EA functions as subordinate to, or merely an extension of, IT. The IT mindset of needing to be told every requirement, of working in projects, and of being more aligned to the IT industry than the business of the enterprise in which IT finds itself, is fatal to EA. EA must engage with the business; in fact, it must break down the distinction between IT and the business. Regrettably, too many EA units cannot break out of the IT mindset.

It is against this background that Jim Luisi's Pragmatic Enterprise Architecture stands as a clear and comprehensive vision of how EA can be done and should be done. Jim has taken his experience in EA and a variety of technical IT fields and synthesized an approach that can be implemented. A key concept that Jim has put forward is that EA is not a single discipline, but a constellation of many disciplines. It is fair to say that EA has traditionally been broken down into the four main areas of Information Architecture, Business Architecture, Technology Architecture, and Application Architecture. However, Jim goes far beyond this to show how EA is really many disciplines which EA brings together to make work in harmony, rather like the conductor of an orchestra.

Intuitively, this makes sense. After all, how can an individual who is an expert in data obfuscation fill the role of an expert in analyzing business capabilities? These architectural disciplines are also bound to come into being as overall information management advances, and disappear as old ways of doing things fall away. Thus, the role of an Enterprise Architect is to understand what disciplines need to be brought to bear on the enterprise, and to ensure that the disciplines relevant to an enterprise are staffed and functioning well.

Jim also points out the flaw in the opposite approach, whereby generalist enterprise architects try to address specific disciplines. In the first place, all generalists will carry with them a set of experience, which is likely to be concentrated in just a few areas. Second, the generalist may simply not recognize the depth of knowledge required for a particular discipline, perhaps even failing to recognize that such a discipline actually exists.

A further set of problems exist because technology and methodologies change over time. Long ago, when mainframes ruled in enterprises, data was thought of as an uninteresting by-product of automation. In those days, the automation of hitherto unautomated manual processes was the focus of IT. Today, automation is prevalent and packages for operational systems exist for an incredibly wide array of enterprise needs. By contrast, the role of data has become increasingly elevated to the point where today the value of data is almost universally recognized. Over this period, the ascent of data has been accompanied by new technologies, such as relational databases, and new methodologies such as data warehousing.

EA must therefore be careful to stay updated with the new architectural disciplines that are needed, and be prepared to de-prioritize disciplines that are declining in importance. It is therefore very important that Jim has included a number of sections on Big Data and its implications for EA. Already we see enterprises rushing into this area and willing to spend large sums on standing up technology. Yet without the understanding of the disciplines involved, there is likely to be a high failure rate, and anecdotes of this are already circulating. Jim's sections on Big Data are particularly welcome at this point in time, because they build on disciplines around data that are necessary to manage traditional relational data, but which again have often been poorly implemented in many enterprises.

Another major architectural challenge that many enterprises are struggling with today is complexity. Complexity is difficult to understand because it is very often the outcome of historical processes. As noted earlier, 50 years of organic growth have created complexity that is difficult to understand, let alone manage. Innumerable decisions made to get projects done in the short term have led to the gradual emergence of massive problems in the long term. This is outside the experience of many IT staff. Such professionals may have experienced working on many projects, all of which were deployed in time and met the requirements they were designed for. More likely, these professionals will have experienced many failed and suboptimal projects. Yet, even if a long series of projects has been successful as individual projects, they typically do not work well together for the enterprise. IT professionals fail to grasp how a set of “successful” projects can lead to a crisis of unmanageable complexity in an enterprise, leading to a situation that prevents business change and inhibits the adoption of new technology.

Again, Jim speaks to the issue of complexity. The role of EA in “doing the right thing” is emphasized throughout this book, and the architectural “big picture” is held up as a constant reference that informs the activities of all the varied different architectural disciplines.

Complexity is made more difficult to deal with today due to another outcome of another set of historical processes, by which enterprises have gradually lost the ability to abstract the business away from the technology. As Jim points out, long ago when processes were entirely manual, staff understood what the business was doing. Today, staff typically interact with automated systems; they understand how to work with these systems, but not necessarily the business goals the systems are trying to achieve. Further, staff cannot see how all the systems work together to make the overall enterprise work. Again, long ago, when everything was manual, staff could actually see how things were done and talk to the people who were doing them. Of all the challenges that Jim outlines, this one is the most worrying to me. Relatively few individuals now exist in enterprises who really can really think about the business independent of the technology that is supporting it. This problem seems to be getting worse as the years go by. One symptom is that when an application is replaced, the idiosyncrasies of the old system are perpetuated into the new system since nobody really understands why they are there, and are afraid to change them. Again, this is an issue that Jim tackles, but to find out more, you will have to read the book.