If enterprise architecture had its own anthem, would you stand for it, or sit in protest?
Okay, maybe that’s an unfair question.
But when it comes to the future of enterprise architecture (EA), regardless of the original intent of EA, people are going to loyally line up on different sides of historically contentious points: the actual meaning of “enterprise”; overreliance on the exclusive use of tools; the components, size, responsibilities, and characteristics of an optimal EA team; and the question of the “academic” dimension of where EA ends and its practical application begins.
This healthy discussion, while passionate and colored with skepticism at times about EA overall, proves one indisputable fact: Many people have strong feelings about EA and are vested in its future, while others dismiss it as too much overhead, too fuzzy, and simply not mature enough as a discipline to add measurable business value in the near-to-medium term.
There has been confusion about EA since this discipline started gaining traction in the late 1980s, after John Zachman published an article describing a framework for information systems architectures. Eventually, Zachman regretted initially calling his framework “A Framework for Information Systems Architecture,” instead of “Enterprise Architecture,” because it may have contributed to EA being perceived as only related to information systems/information technology (IS/IT) and not really something for business transformation. To complicate things further, many considered Zachman’s schema or ontology as an EA framework, which it truly is not.
Three decades later, EA is still somewhat hamstrung by the perception that it is overall academic and very much linked to systems and IT and therefore not something in which senior business leadership need necessarily invest. Currently, one of the most popular (and actual) EA frameworks in the world is TOGAF®, but many still consider it mainly as something for IT and, in fact, it doesn’t clear up the notion of what an enterprise truly is in terms of the establishment of an EA practice. It just rightfully emphasizes that such a practice should be carefully intermeshed with all the other frameworks and methods in place for business- and technology-related decision making. In other words, it emphasizes that every organization must ultimately develop its own EA framework with the understanding that a knowledge of TOGAF can greatly accelerate that progress.
It’s important moving forward for business transformation and EA that the perception of EA change to reflect a broader, more holistic transformational change in a business, including regarding business processes, investments, innovation, security, or even overall business strategies and models.
To achieve this, there has to be a better understanding of the terms “enterprise” and “architecture.” For example, there have been questions for decades about what an enterprise is: Can it be for a large system/program (not just an organization)? Can it be just a line of business or a focused transformation, such as an EA Wiki for more collaborative planning—maybe initially just for one line of business? Must it really be a whole enterprise to start? Can’t it be used in initiatives where multiple organizations are collaborating? How does it differ from “system” of systems architecture? Similarly, confusion about the term architecture is inherent in the term itself because it is the same one used for the discipline of designing cities, buildings, houses, etc.
Despite the feeling about EA today, people leading business transformation will, I think, in the not-too-distant future, concede that architecture work, perhaps more tightly linked to strategic and design thinking, is essential for coherent business transformation, especially to evolve with increasing clarity of the bigger picture—the architectural landscape—and how one significant change in building blocks impacts other ones in the scoped “enterprise” (system of interest).
So, business transformation is actually more likely inclined to accept and invest in Essential Architecture, a new meaning of the EA acronym, and not so much the unending disputes of exactly of what an enterprise is and which enterprise(s) or part of an enterprise is being architected. In short, architecture is, in fact, essential. The proper scoping of it initially and over time will always remain a challenge, but one can more effectively capture design elements of the scoped transformation thinking in terms of Essential Architecture.
One could also appreciate the value of “Ecosystem Architecture” as another complementary way of thinking about EA, but the term ecosystem has many different meanings associated with it, although one should think of one’s ecosystem (relevant industry) and the planet (being eco-conscious) when doing EA.
One thing that is clearly essential to many organizations—and potentially to their detriment—is the overreliance they have on tools to plan and analyze EA-related change. A single tool, even a supercomputer, is not going to be a “silver bullet” to master the architecture landscape. Some kind of EA framework or methodology is more important up-front than any tool or set of tools. Therefore, decisions about the knowledge, skills, and maturity (KSM) related to doing EA should precede major tool decisions and associated investments.
Briefly, there needs to be an understanding of what an organization-specific EA framework does for the organization, what an architectural definition does, and a vision of roles, responsibilities, and workflows. Tool rollouts need to be complemented by EA training to achieve the maximum benefit. Also, EA-related tool investments should incorporate the need to have at least one to two dedicated experts in the tool within months of the instantiation of the EA tools as part of the planning tools landscape. Many organizations are willing to spend millions on tools and associated, mass training, but not on a couple of dedicated experts.
Linked to the introduction and maturity of EA in organizations is the need for them to have their strategic planning offices collaborate more closely with their architecture, portfolio/program management, business/ systems analyst, procurement, and human capital management teams, in order to leverage the knowledge of funding streams and staffing plans with business and technology trends, strategies, and models.
Another area that will play a critical role in the future of EA is the makeup of EA teams. Defining the team—enterprise architects, domain architects, solution architects, platform architects, and subject matter experts—and its size and scalability, along with the enterprise itself is essential. Highly capable, knowledgeable, skilled, and mature teams that can scale in response to business demands must move high-priority initiatives more rapidly in the desired direction. Just as EA teams (core and extended) must be designed to scale up, they must also be designed to scale down when appropriate.
Sometimes, though, the above recommended direction for a much more collaborative and interwoven approach gets muddled through often “traditional” EA initiatives where the EA objectives don’t include the basic: solving the business problem or seizing the business opportunity. Validating this are common criticisms of EA, which largely revolve around the perception that EA is too academic in its philosophy—and that it has an “ivory tower” complex. In light of such criticism, solution architects are often the main focus for change. However, solution architecture without EA usually suffers from silo approaches to problem solving.
It is increasingly the case that EA start-up programs must show value in the first six to nine months, or they will be moved from strategic to largely tactical operations. Even with the requisite, mandatory, top-down support for an EA program, business leadership expects tangible results within a reasonable time period. EA must show relatively soon, even in a focused area, that it is in fact making a difference in the understanding of and planning for increasingly complex architecture landscapes supporting dynamic business capabilities.
EA has to be seen as crucial to problem solving, while mapping out practical approaches to scoping and solution development, reinforced by the ability to answer key stakeholder questions quickly and in compelling ways. An understanding of the relevant ecosystem, touch points, charter, and the areas that will produce the biggest impact is required. There also must be an ability to quantitatively and qualitatively “dashboard” the role and value of EA throughout the system’s development life cycle of major transformation investments.
In my optimal EA world, the future of an EA capability would include artificial intelligence, big data analytics, automation, and the improved integration of various roles and responsibilities in terms of transparent workflow. In addition, I envision that the EA capability must be able to contribute to the generation of CEO-worthy visuals, leveraging extended graphics talent and smart tools that can create outstanding models and animation for top-notch communication of the challenges and options to meet them. The EA team would also increasingly leverage simulations to improve its scoping and road-mapping capabilities. Such an EA capability would be linked to very intelligent, extended ecosystems managed by overall lean and agile core EA teams. Organizations want answers about their architectural landscape. EA can not only help organize the thinking but also determine how to solve the right problem.
While evolving to be more compelling in an innovative and visual/artistic way, EA also has to evolve into more of a science. Through modeling and artificial intelligence, EA will be able to better understand the necessary roles, skills, and knowledge to develop and evolve the proper framework for any organization/transformation initiative.
With the disruptive business and technical models being used this decade, many organizations are looking to EA to help with the collection of requirements to satisfy the concerns of key stakeholders. In reality, EA can help people better understand the drivers, goals, and big picture, and leverage best practices to solve certain problems that are the domain of expert solution architects working closely with enterprise architects.
The right dose of EA (perhaps Essential Architecture?)—the correct combination of knowledge about increasingly disruptive business and technology trends— will enable organizations, now and in the future, to more successfully implement intelligently and creatively architected solutions.
