Authors: Brenda Yu and Saurabh Mittal, PhD

Developing an EA includes all the activities associated with creating and maintaining the enterprise architecture for a specific purpose. The EA provides the blueprint for transforming the enterprise from the current state to the desired end state in order to achieve strategic outcomes. That desired end state may address organizational change, business process transformations, data integration, systems reengineering or technology modernization. The EA describes how to systematically evolve to that end state, often in phases. Development activities are directed at creating or enhancing systems or capabilities (including services) for an organization. An EA, as a tool that describes the high-level context and relationships into which a new or evolved system must fit, is both a guide and a constraint to development activities. An integrated EA tool may also organize business, functional, and technical requirements that drive the design and implementation of detailed solutions. EA standards prescribe both choices and constraints that are imposed on the design, development, and deployment of the solutions.

During the development phase, an EA can be used to reinforce understanding of the relations among the different architecture layers – business, data, application, technology – for the entire project team to include designers, developers, program management, and others. It is not just the business stakeholders who can look to the EA for a clear line-of-sight from strategic goals to project investments to supporting applications that demonstrate business performance; from an implementation perspective, the technical and functional team members also need to assure alignment between the business processes and their supporting applications, or between the applications and the technical infrastructure, etc. EA tools with visualization capabilities are especially suited for displaying these interconnections and facilitating such cross-team review sessions. EA artifacts must be developed with a clear understanding of how the EA will be used and who will use it. To the system designer, the EA may be used as a tool for evaluating design alternatives and selecting optimal solutions. To mission users, the EA may provide insights into how practices will be streamlined or improved through automation. To financial managers, the EA may offer a plan for needed investments and an understanding of what costs savings will be achieved through consolidation.

EA architects apply standards in the governance of solution design and implementation in accordance with the target architecture. Taking a top-down approach, the enterprise architect derives standards from the upstream business prerogatives, architecture principles, and industry standards. As business solutions are built by project teams, standards may provide explicit guidance in the selection and usage of technology. Hence, standards can also evolve bottom-up, as the corollary of the best practices and lessons learned during the projects. For instance, projects may develop common software components serving similar needs during their solution development, which may then be formalized into a set of reusable libraries and frameworks that improve consistency, reliability, and productivity in future projects serving the enterprise.

The EA developer may select from a variety of standards-based reference models, frameworks, processes and modeling notations, keeping in mind the anticipated uses of the EA. In addition, the vendor community has produced a number of commercial tools to support efficient EA development, analysis and use. The EA developer will also need to decide how to collect the data that is relevant to the EA. Information may come from legacy resources, e.g. designs of current systems or documented business practices. The EA developer may need to generate new information by instrumenting and monitoring current or pilot systems, conducting experiments and exercises, or conducting research into the capabilities and risks of new technologies and practices under consideration.

Some of the considerations undertaken in developing an EA are:

• Business requirements and value proposition
• Methodologies and Processes
• Architecture Frameworks
• Tools
• Standards
• Data and Information management
• Project management
• Change management
• Reference Models and Architectures

EA development is a complex activity involving many stakeholders, architects, system engineering and developers. Communication through an integrated enterprise architecture model plays a key role in ensuring all the stakeholders remain satisfied and raise the needed concerns when appropriate.

Further Reading

1. Langade, S., Bombosch, U., Bente, S., 2012, “Collaborative Enterprise Architecture”, Elsevier Science, Morgan Kaufmann.
2. Lankhorst, M., et al, 2013, “Enterprise Architecture at Work: Modelling, Communication and Analysis, Third Edition”, Springer.
3. Luisi, J., 2014, “Pragmatic Enterprise Architecture”, Elsevier Science