Wikipedia defines an Enterprise Architect (EA) as 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. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes.”
On a daily basis, an EAs activities can change quickly and dramatically. I won’t go into organizational models of enterprise architecture organizations. but we’ll explore the role and responsibilities of an EA. Understanding the role of an EA will help us understand the typical daily challenges.
Technology expertise is an obvious skill required for a true EA, but technology skills are not the only skills you will need. There are other essential skills:
- Motivational – EAs must be able to motivate and inspire. A large part of the job is to influence or evangelize ideas.
- Negotiation – There will be times at meetings when an EA must negotiate to get things accomplished.
- Critical Thinking – Being able to think quickly and see the “big picture” is essential
- Problem Solving – EAs must be able to evaluate and solve problems
- Big Thinking – An EA must avoid tunnel vision and being able to look at a problem from multiple angles
- Business savvy – To really understand how technology will affect the business
- Process Orientation – Thinking in terms of process is essential for an EA
- People Skills – An EA’s job requires interacting with people constantly
There are impacts to multiple areas, each of which has its own unique set of challenges. The three major areas that should be considered are:
- Production Processes – These processes support the promotion of software to production environments, change management, and support of solutions after they are in production.
- Production Systems – Systems that are in the production environment are often not isolated; they are deployed and configured into environments that have dependencies and restrictions.
- Production Teams – Teams that support and deploy these solutions have unique processes and procedures. There is both a process and an organizational perspective on this.
EAs should be mindful of production processes because they affect the cost, quality, and resiliency of software. EAs can have a positive impact on these processes by being involved in the following core production processes:
- Configuration Management – EAs can optimize these efforts, both in the design of the architecture and in providing insight into the rest of the organization, possibly standardizing this process.
- Change Management – EAs are typically not involved in this process, but they need to be mindful of the impacts to solutions since they could have many different relationships with other solutions and altering a solution could create downstream challenges.
- Incident Management – EAs do not generally engage in this process either, but they need to be mindful of it because incident management data can be of great value. The data collected here can correlate with other data to help EAs gauge how much an architecture costs.
EAs perform a set of activities that involve existing production systems quite often. By doing so, they serve multiple roles, both in participation and leadership for the following activities:
- FutureState Architecture – When EAs determine a direction for a set of business problems, a solutions road map and architecture envisioning occurs.
- CurrentState Review – This process involves an EA engaging with a LOB owner or post-production maintenance teams.
- Strategic Initiatives – EAs can shape strategic initiatives that result when other forces besides a formal planning process trigger evaluation of current solution architectures.
EAs encounter both technology and operational aspects when reviewing and re-architecting solutions. It’s important to keep in mind that these concerns are not just related to software, but can include a mix of hardware, communications, and software aspects. These aspects stem from a set of enterprise functions, which include:
- Shared Services – EAs consider whether or not particular solutions should use shared services.
- Solution Dependencies – Solutions often communicate with other solutions for additional functionality. Unless the current state architecture is fully mapped, there is a seemingly endless amount of interdependencies throughout enterprises.
- Environments – EAs often consider unified management and consolidation of platform environments.
- Constraints – EAs take in limitations or constraints to architectures for various reasons. Some COTS-based solutions limit the API usage, for example, while other custom-developed solutions are built not to be extensible.
Various post-production maintenance teams are required to do most work on existing architectures, because design documents are created during the SDLC process that can quickly become outdated. Unless the architecture is fully documented through the post-production life cycle, EAs rely on these teams. Teams that are engaged usually consist of:
- Maintenance Team
- Operations Team
- User Support Team
These teams offer perspective into multiple domains of consideration when making architecture decisions.
You can find more information on EAs here.