Enterprise architecture is both the profession and the result of designing and building an enterprise such as a company.
Surprisingly, this means that the founders and leaders of a company are actually also enterprise architects, since they have designed and built – and am running the company. That being said, most executives focus on their vision for the company, and on organizing, building and growing the business.
They rarely take the time to design their company to be as solid, effective and efficient as possible – and that also limits their measuring the company’s performance to financial reports, which by nature is built on historical data – meaning that when you analyze the financial statements, it’s quite late to address any problems.
So, realizing that any company is at any given time also an enterprise seeking to achieve business goals, why not actually design it – or improve its design – to be a solid, effective and efficient enterprise? In fact, as described in Enterprise Architecture As Strategy: Creating a Foundation for Business Execution by Jeanne W. Ross, Peter Weill, and David Robertson, many of the most successful businesses have adopted enterprise architecture practices to get ahead of their competitors.
Enterprise architecture practices recognize that creating and running a business means creating a setup for executing the envisioned business model:
The founders need to acquire facilities to work in, organize workers, figure out what everyone needs to be doing, buying and start using hardware and software, perhaps stocking up on goods and/or raw material, marking the sellable products and services, delivering them and collecting payment – and amassing enough funds to not have the whole endeavor collapse before it really takes off.
With all that in mind it’s not surprising that many businesses accumulate a larger-than-necessary, and often quite disorganized setup over time.
Enterprise architects can help inventory and assess the current setup, and outline a roadmap towards a more robust, efficient and manageable setup. In this activity, enterprise architects refer to an understanding of the key elements of the enterprise that fall outside the scope of CRM, ERP and other frequently encountered repositories:
This generic enterprise information model illustrates which elements are relevant to inventory and assess.
Enterprise
The enterprise is the company itself, which exists to execute its business model, maintain business continuity and possibly grow.
Every enterprise is comprised of the same elements – resources and processes, backed by partner, financed by capital (which is a resource in itself), replenished by revenue from selling products and services to customers. As such, every enterprise has an architecture – an enterprise architecture – which can never be anyone else’s responsibility than the CEO’s.
Realistically, the enterprise architecture is a shared responsibility of all C-level executives, but it also rests with everyone else in the organization to adhere and contribute to it.
In reality, many companies don’t have a carefully engineered enterprise architecture. Instead, it’s a mess of hardware and software accumulated through mergers and acquisitions, ungoverned departmental investments, proprietary and undocumented processes, no or too few or irrelevant KPIs. Basically, an ineffective, inefficient and fragile platform for executing the company’s business model.
This is too often the case even in companies that appear to do well when you look at their financial statements. A company can make as much – or money – as its competitors, even with a poorly designed enterprise architecture. Most likely, the competitors have equally badly designed setups, and sometimes companies just keep getting away with covering wasteful management by increased prices because its customers manage to pass on the buck by increasing their prizes correspondingly.
But rather than basing your company’s survival on luck and weak competition, why not actually engineer a well-functioning, perfectly fitting and lasting enterprise architecture to optimize your business model execution?
And while this eventually must be seamlessly embedded in the day-to-day work everyone in the organization does, you can enlist the help of an enterprise architect to get started.
Capabilities
Capability is the ability to achieve a goal through a course of action.
At the highest level, your company must be capable of executing its business model, but that generic capability is best broken down into more specialized capabilities – often illustrated in a capability map:
Each capability should be backed by relevant processes measured by KPIs, and teams of workers with skills matching the roles defined in the processes.
While a newly developed capability map helps reveal which processes should be established, it’s more often created in companies that have been operational for years. In these cases, it’s helpful in assessing the viability of currently defined processes as well as assessing how well the current organization matches the necessary capabilities.
Processes
Processes are sequences of activities that lead to an intended result. Some activities involve the use of software for inputting data, retrieving data, calculating data and sharing data with others as reports of with other systems via integrations.
Of course, processes may need more than just information – manufacturing processes may need machines, tools, robots, and raw materials.
Many companies don’t document their processes, but those that do often illustrate how to use software directly in their process specifications, which is certainly very practical.
If, on the other hand, you’re setting out to specify requirements for new software to support improved or entirely new processes it’s recommended that you write use case specifications and link to them from your process specifications.
Information
A key element in enterprise architecture is the information model that describes the business entities like customers, products, services, employees, contracts and so on.
All the company’s many applications work with the data that essentially represent these information entities. Agreeing on a common enterprise information model greatly helps solution designers create architectures with recognizable data models that can be easily mapped to the common information model.
KPIs
Key performance indicators, KPIs, define how to measure a process. If you map your processes to your capabilities, and define KPIs to measure your processes, you indirectly measure the performance of your capabilities.
Roles
Roles define the necessary qualifications workers must have to execute processes.
Workers
Workers are employees and contract hires who are organized in groups and who execute processes that requires a role they can fill.
Departments
Teams organize workers according to expertise and responsibilities. Companies often organize their workers in teams that match their capability map.
Facilities
Facilities can be building on premises or remote (cloud) data centers.
Platforms
Platforms are local or remote environments that runs software and stored data.
Applications
Applications are home-built or off-the-shelf software that runs on hardware and loads, manipulates, presents and stores data on hardware.
Requirements
Requirements are conditions that must be met by a software product. Requirements for functionality are best specified as use cases.
Use cases
A use cases specifies how the software behaves when used to perform an activity in a process.
Data
Data is the actual software specific representation of some of the information in the enterprise architecture.
Documents
In this context, documents refer to enterprise and solution architecture documents. Documents I always ask to see – or recommend creating – are:
- Enterprise architecture document
Writing an enterprise architecture document based on a well-designed template ensures that you cover all key aspects and can communicate it to everyone in your organization. It helps you realize which ears you need to explore further, or redesign because documenting the current setup reveals problems that weren’t apparent before.
- Solution architecture documents
Processes and the supporting hardware and software are often developed as solutions to a limited area of the business. This ideally follows a well-designed development process, which ensures the that the project team develops the right solution and gets it properly documented in the process.
- Process specifications
Process specifications explain how to perform tasks well – meaning efficiently and thoroughly and resulting in exactly the desired outcome. They are typically created during the development of new solutions but also sometimes in the course of continuous improvements in various business areas.
- KPI specifications
Key performance indicators define how to measure a process (not the worker). If there are no KPIs defined, or they aren’t actively followed and acted on, it’s difficult to know if your processes work – and thereby your overall capabilities exist at all.
- Requirements specifications
Specifies requirements for solutions and typically created in the course of developing new solutions. Often focused on commercial aspects, constrains and principles for the new solution (some of which many confusingly call non-functional requirements). Functional requirements are better specified as use cases.
- Use case specifications
Specifies a system’s behavior during a specific use in an activity in a process.
Most companies never get around to creating any of these, or they fail to maintain them over time, which essentially means they can’t account for how they operate and how likely they are to be able to maintain business continuity.
Assessing and documenting enterprise architecture
I’m occasionally asked to assess a client’s current application landscape (and possibly the infrastructure) to help management gauge the potential for reducing cost from eliminating unused licenses, utilizing hardware better, and lowering operational risks.
I’m always very clear about my approach to such a task. I will present my findings as an enterprise architecture document based on my own template.
The order of the chapters in the template largely follows the order of specific topics I study and document when assessing or designing enterprise architecture.
The scope of my assignment dictates which areas will be studied most thoroughly, and I’ll clarify to which extent (even if none at all) I have explored each area.
Investing in enterprise architecture
Your enterprise architecture defines and supports your execution of your business model (often expresses in mission and vision statements, strategies and operational plans), and the responsibility for the enterprise architecture capability lies with your CEO and by extension the whole C-level management team.
Since most C-level managers are specialized in their respective fields, they’re usually less equipped to implement enterprise architecture, at least initially. Therefore, it makes sense to hire an enterprise architect to assess, document, improve, and help institutionalize your enterprise architecture capability.
While this change should certainly be facilitated by an experienced enterprise architect, most of the work is to optimize processes and IT, which requires business analysts and solution architects.