Extended Enterprise Architecture Framework

Background

Jaap Schekkerman developed the Extended Enterprise Architecture Framework (E2AF) in 2002 in the Netherlands, along with the Institute For Enterprise Architecture Developments. The framework was the result of several years of real-life experience of using other frameworks such as the Zachman framework, EAP (Enterprise Architecture Planning), IAF (integrated Architecture Framework), and the Federal Enterprise Architecture Framework¹. Thus, the E2AF was heavily influenced by these frameworks. E2AF was described as a Communication Framework that could be used to address the topics and relations between all the stakeholders in an enterprise architecture program². The word “extended” in the Extended Enterprise Architecture Framework refers to everything (elements, relations, and influences) that touches the boundary of an enterprise. One of the important thing that set the E2AF apart from other framework such as the Zachman framework is that while the Zachman framework allows user to separate the enterprise or part of the project to fit into the framework, E2AF is designed with integrated approach and stated any complex organization that is operated by multiple different components together must be designed as a single entity. E2AF emphasizes the holistic approach when it comes to enterprise architecture. This includes both business and IT, business strategies for the future must align with IT structure, and vice versa. And every stakeholder in the organization must work together to achieve the same business goal³. Another thing that sets the E2AF apart is the style element of the framework, which reflects the value of the organization. The E2AF also places a strong emphasis the designing an enterprise that is flexible and dynamic to stresses and changes to the threats and opportunities in the continuously changing market. One important note is that the purpose of the E2AF is to create a collaborative environment for different entities within a complex organization and not an implementation approach. The final goal of the E2AF is a common vision of the future for every part of an organization and to create a set of normative results in which the organization can develop solutions that can be validated by real-world solutions¹.

Major enterprise architecture issues

• The framework is highly theoretical
• The framework is rather rigid
• Lack of direction for continuous operation

Analysis of the Major Enterprise Architecture Issues

The framework is highly theoretical

In the Jaap Schekkerman’s own words, the E2AF was influenced by the Zachman Framework and just like the Zachman Framework, E2AF also has the negative side of the Zachman Framework and is highly theoretical and the 4×6 table of the framework is also rather generic. The framework, and the preferred term of the industry, “business eco-system,” are both vague and thus represent a problem when an enterprise wants to adopt the framework. In the case of E2AF, it could be much more complicated compared to the Zachman Framework since it incorporates the collaborations between different entities within the enterprise. The E2AF was also designed to be generic with a “one size fits all” approach where it is supposed to work for every enterprise, under any circumstances. But in the market, every company is unique from one another. Even within an enterprise, different parties can have different understandings of the same issue. Therefore, trying to fit the entire enterprise into a generic framework would do more harm than good for the organization. Similar to the Zachman Framework, E2AF cannot be considered to be a methodology but a modeling tool in which the leadership can use to fill in the gap between different states of a project within the enterprise, from the current infrastructure (as-is) to the targeted goal (to-be). The framework could be useful to take a snapshot of the taxonomy of the enterprise and the vision it has at a given time in order to produce documentation for better management and planning of the organization.

The framework is rather rigid

One thing about the E2AF is that the framework is specific toward the stakeholders within the enterprise⁴. In order for a successful adoption of E2AF, the roles of the stakeholders must be well defined as much of the responsibilities for adopting the framework, such as creating “Level of business collaboration,” or “Type of Inter Connection”, is with the stakeholders.  For example, in the “Why” Abstraction Level of the framework, “extended business drivers” needs to be defined for the Business Aspect Area, and under the Information System Aspect Area, the “Enterprise Responsibility of IS” needs to be defined. And in each cell of the framework, the end goal of the tasks is listed as well. While this can sound like a good thing when each cell has specific tasks to meet the end goal, the generic aspect of the framework turns this rigid framework into the problem. The framework is very specific about each individual task, but it is very vague about the specific responsibility for each specific stakeholder. This means that within an enterprise, it is possible that adopting the E2AF can produce different results for different stakeholders. This is very likely when those stakeholders have different architectures, or the enterprise relied on legacy systems before the adopting of E2AF. It is challenging to attempt to implement any single framework to the entire enterprise where each different stakeholder might have different differences between the existing architecture and new architecture that the enterprise is trying to implement. This can lead to misalignments between stakeholders. To build a successful enterprise architecture, every stakeholder in the organization must implement the new architecture at the same level and must be able to communicate, sharing of information with one another. As long as there is one stakeholder that could not adopt the new architecture at the same level as others. The implementation can be considered a failure. Another issue raised by the rigidity of the framework is that E2AF is time-sensitive, in which the life cycle of implementing the framework is short and the enterprise needs to get to the stable phase of the framework within the organization quickly. Tambo in 2017 explained that this is due to the fact that the market has continuous changes. Utilizing the E2AF, the organization could produce documentation for the as-is state and the documentation for the transformation into to-be state. The quicker the implementation of the framework, the more likely that the vision of the leadership had by implementing the framework to be correct to the market situation and produce positive outcomes. Even then, when adopting the framework, it must take into account possible major events that could have significant impacts to the operation of the enterprise, such as mergers, obsolescence in technology, or changing business focus… All of these events could result in the invalidity of the framework.

Lack of direction for continuous operation

As discussed above, the E2AF is not a methodology, but merely a modeling tool for the leadership to manage the transformation between the “as-is” to “to-be”. And similar to the Zachman Framework, the “to-be” stage depends solely on the enterprise itself. The E2AF offers little guidance in developing a correct one. The framework can help the enterprise get to the “to-be” phase faster, but it is not necessarily the correct one. This means that if the vision of the future for the enterprise was developed in the wrong direction, the result of deploying the E2AF would be a significant setback for the whole enterprise, especially when a rigid model such as the E2AF was used, this could lock the entire enterprise into a model that it would be impossible to change to different, more suitable approach.

Current Status of the Framework

Since its conception in 2002, the E2AF has had little to no modification to its overall model. E2AF is a young framework compared to the Zachman Framework (1987) and TOGAF (1995), and also one of the least popular frameworks being used. In 2005, about 9% of the enterprises in the world were adopting E2AF, compared to 25% of Zachman Framework and 11% of TOGAF⁵. As of 2017, E2AF was still unpopular with very little research paper published on the subject, and the published ones received very low citation number in the academic circle. Besides the work of Jaap Schekkerman himself in 2004, most other works on E2AF by other authors received less than 20 citations⁴. E2AF is considered to be a weak framework both in term of academic and practical⁴. More search and development are required for the framework to be more widely adopted in the future.

Conclusion

The E2AF was born in 2002 and was a slightly modified version of the Zachman Framework. E2AF was an improvement with a holistic approach to enterprise architecture, with the concept that when every stakeholder in the enterprise operates together, they must be designed together⁴.  The framework also considers the collaboration of different stakeholders within the organization. The framework also provides the viewpoints Privacy, Governance, and Security. But the vagueness of the language, the lack of defining stakeholders makes the E2AF a rather weak framework. E2AF has many problems. E2AF just like its predecessor, the Zachman Framework, is too theoretical to have any practical usage. While promoting collaborations, E2AF lacks the necessary tool to lay out the differences incompatibilities between stakeholders. Without solving these barriers between the parties involved in the project, forcing the collaborations between stakeholders would have negative results for the organization. The rigid nature of the framework is also something future researches need to address. While being rigid on the task, end goal for each cell in the framework, the exact role, responsibilities for each different stakeholder are not defined at all in the E2AF. Any enterprise before adopting the framework, the stakeholder’s responsibilities for each task need to be well addressed to have a successful implementation. Any inadequacy in this step would bring major impacts, delay in deploying the framework. E2AF is an unpopular framework. Very little articles, research literature are written on the topic. This could be due to the similarity between it and the Zachman Framework, which is much more popular in the industry. To improve the practicality of the E2AF, much more research on the subject needs to be done, especially in guidance in defining roles and responsibilities for each and every party involved in the project.

Recommendations

• Provide methodologies in the framework.
• Provide guidance on assigning the responsibility for each stakeholder
• More research and development needed for the framework
• Provide more guidance on possible changing direction with the framework

End notes

1. Jaap Schekkerman. How to survive in the jungle of Enterprise Architecture Frameworks (Bloomington: Trafford Publishing, 2004), 91.
2. Jaap Schekkerman. Enterprise Architecture Good Practices Guide p- How to Manage the Enterprise Architecture Practice (Bloomington: Trafford Publishing, 2008), 257-280.
3. Jaap Schekkerman. Extended Enterprise Architecture Framework Essentials Guide, Version 1.5. Institute For Enterprise Architecture Developments (2006): 1-26.
4. Torben Tambo. Enterprise Architecture beyond the Enterprise – Extended Enterprise Architecture Revisited. ICEIS (2017): 381-390.
5. Jaap Schekkerman. Trends in Enterprise Architecture. Institute For Enterprise Architecture Developments (2005): 1-33.

Bibliography

• Schekkerman, Jaap. How to survive in the jungle of Enterprise Architecture Frameworks. Bloomington, Trafford Publishing, 2004.
• Schekkerman, Jaap. Trends in Enterprise Architecture. Institute For Enterprise Architecture Developments, 2005.
• Schekkerman, Jaap. Enterprise Architecture Good Practices Guide p- How to Manage the Enterprise Architecture Practice. Bloomington, Trafford Publishing, 2008.
• Tambo, Torben. Enterprise Architecture beyond the Enterprise – Extended Enterprise Architecture Revisited. International Conference on Enterprise Information Systems. Vol.03 (2007): 381-390.