In short, your enterprise architecture is your setup for executing your business model. It follows that you always have an enterprise architecture, regardless of whether it is the random and undocumented result of endless chaotic decisions over time or has been optimally designed and documented to serve your business model execution efficiently and effectively.
The usefulness of your current enterprise architecture is the direct result of your enterprise architecture practice, whether nonexistent or solid.
Bear in mind that an enterprise architecture practice does not mean having an enterprise architecture department in your organization. The practice is inherent in your development process when you run projects to make significant changes, and is continually managed by everyone if you design your processes accordingly.
Ultimately, the CEO must always be responsible for the current enterprises architecture and its management practices. If a solid enterprise practice is in place, this required little or no attention from the CEO.
If you lack a solid practice, it makes sense to bring in an enterprise architect to develop and put a solid enterprise practice in place. Only consider permanently hiring an enterprise architect if there are other relevant activities once the enterprise architecture practice is in place. This might be solution architecture or business analyst work in projects, but if you don’t run many development projects regularly, there’s just no need for a permanent enterprise architect.
Solid enterprise architecture practice
Your enterprise architecture practice is solid when everyone in your organization has the same understanding of your current enterprise architecture, adheres to it, and contributes to its continual improvement. A solid enterprise practice makes your organization more ready to run projects.
The best way to achieve a common understanding of the current enterprise architecture is to document and communicate it, and demonstrate its usefulness in relevant activities. I recommend that you document it using Confluence [Wikipedia] and link to it from your intranet for easy access.
Enterprise architecture documentation
I recommend that your enterprise architecture documentation covers the following topics:
Introduction
Summary
Summarize the current state of the enterprise architecture and this document. Highlight major concerns. Recommend urgently needed actions.
Revision history
Maintain a list of recent changes. Purge old changes as new major revisions are completed.
Business model
Explain the business model and how its elements relate to key elements in the enterprise architecture.
Business architecture
Capabilities
Capabilities are presented as a business capability model [Wikipedia] – also often called a capability map. It presents a structured hierarchy of key areas of expertise required to handle the business model’s key activities. It can serve as a template for organizing staff in corresponding departments, and as a reference when assessing the strength and suitability of the current organization. The business capability model can also help you decide which key activities to consider a process.
There are no standardized methods for modelling business capabilities. Look up examples on the Internet. Keep in mind that a defined capability should define the relevant expertise and resources required to handle one or more related and/or similar processes.
Indicate who is responsible for each capability, and list subject matter experts. Also consider listing key applications that support a capability.
Processes
Processes are arbitrary flows of tasks that each handle a key activity. There are no standardized methods for determining which tasks should be assembled into which processes. It’s possible to draw a process model (for example as a use case diagram [Wikipedia]), but it’s just not very useful, and you risk wasting too much time making your drawing pretty.
Individual processes can be visualized using BPMN diagrams [Wikipedia]. This too can be time-consuming, and not always precise enough, but it still serves as a good introduction to a process.
Indicate who is responsible for each process, and list relevant subject matter experts. The use of an application in a process task can be described as a use case [Wikipedia].
Information
Present an information model as a class [Wikipedia] or entity diagram [Wikipedia]. The information model shows key information entity types and the relationships. It is followed by a detailed description of each information entity type explaining its purpose, attributes or properties, including its relationships with other information entity types.
Indicate who is responsible for each information entity type, and list relevant subject matter experts. Ideally, indicate which applications work with each information entity type, and where data is stored.
Organization
Present an organizational chart [Wikipedia] that shows the hierarchy of departments and incidates who are the department heads.
Locations
Show where facilities are located.
IT Architecture
Infrastructure
Describe machinery and communications equipment.
Environments
Describe servers and connections in each environment.
Applications
List and provide relevant details about all software products.
Data
Visualize where applications store data, describe data structures and which information entity types it represents, and indicate who is responsible for each data representation.
Governance
Describe how the enterprise is managed, and by whom. Explain how development projects interact with the enterprise architecture managers.
Development process
Explain the development process to use for implementing changes in the enterprise architecture.
Tools and technologies
List preferred, available tools and technologies. Mention any currently used tools and technologies that should be avoided and ideally phased out in any change initiatives.
Standards and policies
List relevant standards and policies that must be used and followed in any change initiatives.
Design principles
List and explain design principles that must be followed in any change initiatives.
Roadmap
List ongoing and planned change initiatives.
I recommend that you annotate your enterprise architecture documentation with notes that highlight problems and recommendations for improvement.