Today’s computer and technology systems are complex – especially when they are responsible for so much of the productive activities within most organizations. Physical and cloud servers, applications, and enterprise software all must communicate and share data seamlessly in order to provide the customer a successful and satisfactory user experience.
The holistic view of all these pieces is referred to as enterprise architecture. Guidance surrounding this implementation are often known as enterprise architecture frameworks (EAFs), which we are exploring from a high level in this article.
BMC Helix - The Future of Service and Operations Management
BMC Helix is the first and only end-to-end service and operations platform that’s integrated with 360-degree intelligence. Built for the cloud, this reimagined service and operations experience is unrivaled, giving you:
- Single pane of glass for ITSM and ITOM functions
- BMC Helix ITSM optimized for ITIL® 4
- Enterprise-wide service including IT, HR, Facilities, and Procurement
- An omni-channel experience across Slack, Chatbot, Skype, and more
- Cloud native micro-services platform for your enterprise
- Automation with conversational bots and RPA bots
- More than 7,500 IT organizations trust BMC ITSM solutions. See why and learn more about BMC Helix ›
Defining the Enterprise Architecture Framework
Simply stated, enterprise architecture framework (EAF) refers to any framework, process, or methodology which informs how to create and use an enterprise architecture.
So, what is enterprise architecture?
At a high level, enterprise architecture offers a comprehensive approach and holistic view of IT throughout an enterprise. An enterprise is a business, company, firm, or group of any size that provides consumers with goods and/or services. This can also include any organized unit that has a common goal, such as an industry consortium or non-profit group. An enterprise requires collaboration to achieve its goal or strategy while providing the good or service as best as it can to ensure customer satisfaction.
Because the enterprise must collaborate across disciplines, it relies heavily on technology – storing and collecting data, selling and implementing the good, providing customer service. These various business needs require their own technology to function properly and satisfactorily, which can lead to dozens or hundreds of pieces of individual technology. If they can’t function together, the customer experience probably won’t work smoothly.
While no single definition of enterprise architecture exists, it is understood as a practice or discipline of organizing logic that promotes a health IT infrastructure that makes sense for successful business practices.
Importantly, the outcome of an enterprise architecture isn’t simply organization. The process should convert intangible business strategy to practical, real solutions that can be measured and achieved. Relying on the practices of architecture, enterprises can analyze, design, plan, and implement the technology they need to execute their business strategies. The architecture should also incorporate 21st century practices of business process management and data analytics.
Across the many frameworks that serve to achieve an enterprise architecture, the goal of the comprehensive approach is always to successfully execute strategy with efficiency, efficacy, security, durability, and agility.
History of EAF
A commonly held tenet is that enterprise architecture frameworks date to the mid-1980s, in accordance with the publication of the Zachman Framework, developed by then-IBMer John Zachman. But deeper historic inquiries indicate that enterprise architecture frameworks actually got their start two decades earlier, when IBM produced their business systems planning (BSP), an effort that Zachman helped found.
A researcher of 20th– and 21st-century technology, Svyatoslav Kotusev says that we can look at the history of EAFs in three smaller eras:
- Pre-EA: Originating with IBM, the BSP formalized a methodology that indicates a theory for information systems architecture. It included both a top-down planning approach and an architecture planning process that was divided into a series of steps for a company to follow. The plan, with diagrams and matrices to illustrate its system, can be traced through all EAFs even today. The Method/1 process by Arthur Andersen as well as other BSP-like methodologies from consulting firms and tech experts also originated in this era. Overall, these approaches focused strictly on technical infrastructure, like how to deploy hardware and servers.
- Early EA: This begins in the 1980s and runs into the 1990s, and this era codifies the term “enterprise architecture”. The initial wave of EAF theories include the PRISM, sponsored by IBM among others, released in 1986, the Zachman Framework in 1987, and the NIST EA in 1989. Later entries marked a newer approach in this era including Steven Spewak’s Enterprise Architecture Planning (EAP), which has direct roots to the original BSP, as well as the TAFIM. These later frameworks began including applications and data integration, as systems became more sophisticated.
- Modern EA: Starting in the late 1990s, this era continues to present day. Newer frameworks include the FEAF, which is based on Spewak’s EAP, as well as the TOGAF, a well-known version today, with roots in the TAFIM. Today’s frameworks aim to provide tangible solutions beyond only IT, integrating all layers of an enterprise, including overall strategy, business needs, IT infrastructure, and applications.
Despite the differences in approaches that these eras indicate, all frameworks are generally based on the original BSP methodology, often advocating similar steps or phases for planning and implementing enterprise IT.
Some enterprises look to adopt service-oriented architecture (SOA) or microservices architecture (MSA) (often a key component of establishing a digital transformation) which has an impact on both IT and business processes. These may be the best candidates for enterprise architecture.
At its most helpful, an enterprise architecture framework makes sense of the complexities of achieving business strategy via IT strategy, technology, and business needs across all silos of the company. When performed at its best, an enterprise architecture translates the vague and intangible business strategy to practical, concrete plans and actions. Then, these designs are translated into solutions that achieve business strategy.
Other benefits include improved agility within the business. By aligning business needs across all silos, companies can visualize actual business motives and drivers. This can highlight what’s working and what isn’t, allowing the company to pivot in areas that actually need it.
The blueprint that accompanies enterprise architecture allows the company to understand how all the business IT pieces fit together, which can result in better systems maintenance and support as well as IT management.
Ultimately, successful enterprise architecture leads to better planning and change management – budgets are set, system interoperability is double-checked, and various employee roles can see into the system, offering a common vocabulary that can improve and enhance communication across business needs.
Types of Enterprise Architecture Frameworks
Enterprises can choose from a seemingly endless number of frameworks to address their architecture, and that’s without looking into history to uncover countless more options.
The types of enterprise architecture frameworks are often categorized by who created and released them. Today’s EA frameworks fall into a few types:
- Those developed by consortiums, of which The Open Group Architecture Framework (TOGAF) is most known.
- Those intended for defense industry use, such as the U.S.’s own Departure of Defense Architecture Framework.
- Those intended for wider government use, including the FDIC Enterprise Architecture Framework, the Federal Enterprise Architecture Framework (FEAF), and the NIST Enterprise Architecture Model.
- Those developed and released as open source.
- Those developed by private companies or universities and released as proprietary material, like those from IBM or Gartner.
A company looking for the right EAF must know that these frameworks vary widely, with some providing more structure around the taxonomy, classification, or organization of an enterprise. On the other hand, others emphasize process. As some experts point out, EAFs can vary from processes or full-blown methodologies to more flexible practices. In certain comparisons, EAFs are very similar and repetitive, and others have little in common beyond the name of enterprise architecture framework.
What works best for one company might not work at all for another – and that’s to be expected. Indeed, there’s even considerable debate about the benefits of enterprise architecture frameworks altogether. In many cases, IT governance frameworks like ITIL or COBIT can help to inform the overall enterprise framework strategy.
Criticism of EAFs
Historically, the frameworks tend to offer similar processes to follow when implementing an enterprise architecture, yet there were some problems with these so-called solutions:
- In the Pre-EA era, planning for implementation was prohibitively expensive and time consuming. When plans were achieved, they were heavy and dense, very abstract, and difficult to understand, which means they were difficult to implement across the entire organization.
- In the Early-EA era of the 1980s and 1990s, the strain on resources was still considerable, and the plans were often considered too conceptual and inflexible to be applied practically.
In recent years, we’ve seen a decline in the cost and resources associated with planning that a framework often implies – perhaps thanks to the technology we rely on for this planning. Still, maintaining the documentation is often too cumbersome and time consuming. What is documented, companies find, could be poor in quality and detail, or too quickly outdated to be useful.
While enough technology experts have concluded that EA frameworks aren’t effective or simply a management fad, as the technology that supports enterprise architecture becomes more agile and nimble, this problem may turn out to be less of a problem after all.
Indeed, more recent opinions hold that the demand for EAF is growing, but the challenge to EAF may not be the frameworks themselves, but the way we understand them. While these frameworks are often rigid and structured, which might not align with constant change inherent in 21st century business and technology, using the frameworks as guidelines instead of as gospel may prove beneficial – after all, companies still need a structured approach to infrastructure.
The harder part, indeed as with a lot of technology, may be convincing the company at-large that this approach works. As most employees are so focused on the implementation of a single tool or application, they might not see the benefit of a holistic approach that enterprise architecture can provide.
Who makes a good enterprise architect?
Despite the criticism of guiding frameworks, technology experts and companies often agree that the structure the enterprise architecture provides can be beneficial, and indeed necessary. Whereas a framework has the potential to muddy the waters, a skilled enterprise architect – the person responsible for this holistic vision come to life – may be exactly what a company needs.
Enterprises often employ an enterprise architect whose responsibility includes the overall alignment of IT and business needs to achieve business strategy. Perhaps unsurprisingly, a good enterprise architect isn’t someone who simply follows a framework. After all, frameworks are static pieces of guidance for businesses and technologies are constantly shifting.
A successful enterprise architect is able to understand all the moving parts and relationships within a business, not only within the IT sector of an enterprise. This holistic approach must include strategy, enterprise architecture, and even project delivery to ensure success.
Some proponents of EAFs even see that enterprise architecture can bridge the gap between the IT and business silos that often exists within companies. A strong enterprise architect, then, must be able to collaborate as easily with developers as with senior management.
Hard skills that a good enterprise architect can make use of include knowledge of network administration, traditional systems admin, and even cloud admin; systems thinking and project management; IT governance; and hardware and software knowledge. In studies conducted at large companies who successfully incorporate enterprise architecture, the architect should also be “bilingual” – that is, understanding and fluency in business needs across all siloes, not only IT.
The Future of EAF
While some say enterprise architecture frameworks are unnecessary and don’t work, there is an argument in favor of enterprise architecture, whether it is through a formalized framework or a through a top-notch employee who sees these benefits.
As more and more companies move to the cloud and embrace the flexibility that comes with a DevOps culture, two real things will happen:
- Companies will move away from buying and managing physical servers on site.
- Companies will move towards cloud deployment and high-end solutions, which means there will be a whole new world of various vendor architectures to navigate.
This digital transformation equates to a more and more complex project landscape, one in which customers expert – perhaps demand – to use various channels interchangeably and with equal success, often during a single transaction. A holistic framework to enterprise architecture may be the answer.
One area that enterprise architecture will undoubtedly need to grapple: the “app store mentality”. Smartphones have revolutionized the way the public accesses software – simply go into the app store, click, download, and begin using. There’s no longer the need to purchase physical disks and go through a lengthy install process – or dealing with the ramifications of a single tiny error during install that corrupts the entire process. Users can download, delete, and re-download apps exactly when they need them.
But experts question how this download-and-go attitude will affect a holistic enterprise architecture where things are heavy and significantly less speedy. There is little success for plug-and-play options in a large enterprise architecture, but will this need to change?
At their best, successfully adopted EAFs can bridge the gap between the IT and business worlds – in doing so, the way an organization views and achieves IT can be vastly improved.