What I learned studying Enterprise Architecture
“We think of enterprise architecture as the process for fully describing business functionality and business requirements and relate them to information systems requirements.”
Advancing in my career as a developer, I became increasingly curious about the concept of architecture in software. We often develop the idea of architecture as a cohesive design of our domain of interest. The more I delved into the topic the more I connected it with software architecture patterns and the latest technology. Whenever I thought of architecture, the keywords that came to mind were service-oriented-architecture, pull vs push, AQMP vs RPC, Cloud vs On-premise, etc.
I had only heard about the term of Enterprise Architecture. At first, I assumed I was dealing with the same concept of architecture applied to an enterprise. I was expecting concerns about scalability, architecture patterns and so on. To understand more on the subject, I studied resources provided by the “The Open Group”. They provide a framework for applying an Enterprise Architecture to an organization “The Open Group Architecture Framework” (TOGAF).
To my surprise, during the study material, I rarely encountered IT guidelines or patterns. Instead, I found tools and methodologies aimed to provide a business change to an organization, including IT. I saw my vision was only one small part of a bigger picture — a picture I started to appreciate. To grasp more of the big picture, I picked the study path for TOGAF certification.
Here I will outline some of the main differences from my previous perspective as a developer.
Description
Enterprise architecture (EA) is “a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies.” — OpenGroup
The definition already gives a good hint — business-driven implementation and planning. The Open Group suggests a method for applying EA called Architecture Development Method (ADM).
This method defines the architecture development in phases, outlined in order:
- Architecture Vision -> Focus on understanding requirements and stakeholders’ concerns. Display a draft of the final architecture and how it will impact the enterprise.
- Business -> Design a business architecture and approve it with the stakeholders.
- Information Systems -> Design Data and Application architecture with domain experts based on previous business architecture.
- Technology -> Design the technology platform architecture that will support the application and data.
- Planning -> Group all the required work analyzed in the previous phases into work packages. Integrate with portfolio management to plan the work packages into the organization roadmap.
- Implementation -> Follow the implementation executed by the teams.
- Change Management -> Continuous process to ensure the architecture keeps satisfying requirements, and keep track of new opportunities.
Basically, the result of the ADM is
- The implementation of the systems based on designed architectures
- The governance processes to keep the implementation valid in continuity.
I have simplified the description and phases to give a general idea about the methodology. If you want to understand the ADM more in detail I suggest the TOGAF documentation on “The Open Group” website.
This method is abstract — thought to be tailored for a specific organization. Any phase can be changed, removed or reordered. Despite this, the ADM does apply certain concepts regardless of the enterprise.
Business first
Recognizing the need is the primary condition for design.
Architecture development starts with “Business Architecture” (Phase B), which will provide the basis for application, data, and technology architectures. This ensures a focus on business outcomes while designing the solution.
It might seem simple at first, but how many times have we been driven into technical excellence train of thought with little attention to specific requirements. Developers and IT architects are smart people. They like smart solutions and often get excited about how they will solve the problem. Using “the next big thing” or “finding the perfect tool” can easily become our focus. If not properly managed, this can shift our attention away from thoroughly understanding requirements to build a specific system for it.
TOGAF emphasizes focus on business outcomes first. This does not mean we disregard technological excellence, on the contrary, we focus more precisely on that topic during the respective phases and may even provide feedback on the business architecture. Which brings me to the next topic.
Opportunities in Iterations
Good design is good business.
TOGAF advises an iteration approach to architecture development. That is more impactful than it sounds. As a consequence, it allows a feedback loop through all phases.
For instance, when we are evaluating technology architecture, we can advise about new technology (or lack thereof) that impacts business action. This way, IT may give a meaningful impact on business requirements. For example, some business activity may be simplified or removed thanks to technology such as “we can share this information using the cloud, no need for manual sending” or “we could also sell this online with x cost instead of a door-to-door salesman” etc.
This understanding is realized through the use of a common language: “business architecture”. By interacting with the business architecture, solutions architects/domain experts can communicate opportunities that arise from IT/technology to the business. Business architects and stakeholders may decide to take advantage of this opportunity, changing the business architecture, starting the iteration of designing business, application, and technology. This framework allows a consistent way to provide feedback from IT to the business that allows focussing on outcomes and technical excellence.
Note that the business architecture should be decoupled from technological concerns, but given the rate of technological and product advancement in some fields, they may impact business activity in ways not previously expected.
Architecture is about continuity
Change is the only constant. Hanging on is the only wrong.
The architecture process is not over with the implementation. Enterprise Architecture involves “Change Management” as a continuous process. During this process, we monitor the current state of the architecture. This means we monitor whether original requirements are still satisfied in time and we track new opportunities that may have arisen (e.g new products, new technology, etc).
This approach is interesting, as it treats the architecture itself as an artifact to be maintained — an artifact that involves people, IT and business changes. As a developer, I have encountered situations where to implement new logic, I had to tread lightly and keep track of previous requirements to avoid conflict. This often happens when changing aspects of the software that manage several business processes. This had to be done during the implementation. Having a framework that specifically monitors this, allows for safer changes, better requirements management, and a healthier system.
Architecture is about people
A design isn’t finished until someone is using it.
Enterprise Architecture is about restructuring the enterprise itself around the business strategy. It is less about specific IT system design and more about people and processes. It is tailored for each enterprise to achieve change and a set of continuous activity. In most organizations, the architecture will impact people at the business, IT and portfolio management levels. In fact, one of the main points of TOGAF is the organization’s “architecture capability” — which is the ability of the enterprise to consume the desired architecture changes. In practical terms, this usually means ‘training people’, making sure the changes are well received and understood. You may have the most effectively designed architecture to date, but if people are not able to use it, you are bound to fail.
This is a powerful and down to earth concept to keep in mind. It is the job of the enterprise architect to align all actors into a cohesive process that will bring the desired change and maintain continuity.
Conclusions
Studying Enterprise Architecture provided an interesting point of view for me. As developers, we are problem solvers. Viewing the desired change from the perspective of the entire organization considers a new set of problems and solutions that involve business, IT, people and processes. Understanding these problems is a different type of challenge, one that may initially seem distant from us, but that affects our work and environment. This broadens our vision on how to manage a change beyond its implementation.
