When advising clients on enterprise architecture, helping them implement and integrate ERP and CRM systems, or developing new software for them, I’m often asked to review their enterprise architecture, and sometimes help them document it.
So, just as the business model canvas was defined to help people understand and refine their business model, I have devised an enterprise architecture canvas:
This canvas illustrates what I look at to inventory an enterprise architecture. And it also illustrates the sections in the documentation I create to convey my findings.
While I occasionally am asked to specifically do this, it’s more often just something I do on the fly as part of working on a particular solution architecture. Because this solution architecture will exist within a surrounding enterprise architecture, which makes that enterprise architecture a necessary element to consider when designing the solution.
Locations
Locations are the premises and the office buildings on them in which people work.
Some businesses can function fine anywhere as long as there’s electrical power and internet access (even if it’s via mobile phone). Other businesses have special needs, like backup power equipment, higher security, higher network bandwidth etc.
I rarely find a need to comment on a client’s facilities, but if people tell me that they often suffer from power outages or unstable internet access, I would certainly mention those concerns in an enterprise architecture assessment report.
And if critical systems run on on-site servers I would want to assess whether the facilities protect them from unwanted access or threats from the surrounding environment like flooding etc.
And the recent world-wide Corona virus crisis has shown that the workers’ own homes may have to be considered an extension of the business’ facilities as people may need to be able to continue working from home with little advance notice.
Organization
While the responsibility of the enterprise architecture can only be the CEO’s, most CEOs would not have the bandwidth or sufficient knowledge of technology and methodology to establish it.
To support the CEO an enterprise architect should hold an advisory position reporting to the CEO and the board of executives.
Unfortunately, the enterprise architecture function is usually placed under the CIO, which removes it from direct contact with the CEO and other executives.
Hardware
Hardware runs software (applications and services), and stores data. Hardware can be located on-premises or remotely in the cloud.
Hardware often has built-in firmware, which controls its features. While you can’t shop around for the best fitting firmware for your hardware, you still need to keep it up-to-date with new releases from the hardware vendors to keep your hardware running optimally.
Assessing local hardware involves checking that firmware is kept up-to-date, and that each piece of hardware’s life expectancy is taken into account in roadmaps and budgets.
Also, operating and maintaining hardware requires expertise, which can be costly to acquire and uphold.
Software
Software is something you buy, hire or develop, and run on local or remote hardware. Regardless of how to come by it, it requires an investment to acquire and put to good use. Users need training and support, and their proficiency in the chosen software must be upheld.
Applications
Applications range from small almost invisible utilities, over office tools like spreadsheets and word processing tools, to advances server applications like CRM and ERP products and databases.
APIs
Most applications come with built-in APIs (application programming interfaces), which enable cross-application integration.
Some built-in APIs are more or less wellkept secrets, used by closely integrated software tools in a larger suite, like the Microsoft Office tools.
Other APIs are specifically designed to service complex integrations, something that’s heavily utilized in service-oriented architecture.
Services
Services are also just software, in that each service is a piece of software that runs on hardware. But services are usually designed, built and maintained by the business to integrate complex applications and support complex business processes. As such, establishing a service-oriented enterprise architecture requires an actual development capability, either manned with in-house staff or external hires.
In my many assignments in various companies I have come across countless attempts at categorizing and organizing services in layers. However, I usually find these concepts counter-productive in that they put too many constraints on the design, and end up requiring more code to circumvent the restrictions of irrational architecture principles.
I find it practical to only distinguish between business services, entity services and utility services.
Business services
Business services directly support business processes, and they never ever store any data – they use entity services for that.
Applications should only call task services, never entity services or utility services.
Entity services
Entity services only create, read, update and delete data.
Entity services should only be called by business services.
Applications should never call entity services directly.
Entity services should never call other entity services, so coordinated changes to different entities must be orchestrated in task service.
Utility services
Utility services can provide scheduling, conversion, application callbacks – basically whatever you don’t want to pollute your task and entity services with.
The can call both task and entity services, but avoid calling other utility services.
Data
Data is stored on local or remote hardware, and is created, read, update and deleted by software. Carefully structured and managed is gold, but unstructured and unmanaged data is a burden and a threat to your business continuity.
Application files
The simplest form of data are the application specific files you place in folders on disks. Usually, only the application that created the file, can read it, which makes it difficult to utilize. Sometimes this can be circumvented by building services that access application files via the built-in APIs in the same application.
Application databases
Many applications store their data in databases, and either have built-in database server software or is configured to use a separate database application like Oracle or SQL Server.
Since databases are large standardized, and since the databases offer APIs that enable other applications and services to access their data, such data can more easily be utilized in a variety of scenarios.
Metrics
Metrics are data that record duration of activities in the enterprise architecture. Metrics are small standardized records that identify the measured activity, its start and stop time, and the result. Perhaps supplemented with some identifies that makes it possible to find related data in more comprehensive logs.
Since metrics are small records it’s possible to retain metrics for long periods, enabling trend analysis of the architecture’s performance and capacity.
Logs
Logs are usually more comprehensive, for example capturing complete service request and response payloads, which take up much more space and contain sensitive data.
Therefore logs support incident handling, but can usually only be retained for shorter periods to keeps costs manageable.
Message queues
Message queues contain data traveling between services to retain it until it has successfully been received and processed by the targeted service.
Entity databases
Entity databases contain the data records that make up the entities stored by the entity services.