The Best IT Architecture in The Business, Guaranteed
Experience the difference with our tailored architecture services, which cater to your unique requirements. Read through our blogs and examples below and see how they apply to your environment.
Enterprise Architecture
Enterprise Architecture is difficult and I have not seen it well-practiced anywhere I have been; as an anecdote one of the companies I worked for hired a new Chief Architect while I was there and his initial assessment was that the maturity level of the company’s enterprise architecture was 0, in other words, it couldn’t get any lower. I think that’s too harsh but the fact is, EA maturity level is low across the board in Canada so much so that the question is whether it’s even worth the trouble/costs. I have a few thoughts about this
Here is an example of my custom EA for a recent client. It contains base as well as target architecture; it’s very detailed in the business sense rather than the technical sense. It starts with “logical architecture” which explains in detail how business capabilities within the product domain are accomplished through various enterprise systems and how these systems physically fit into the enterprise infrastructure. The document doesn’t contain solution architecture because the client had a different document template for solutions.
Example of Enterprise Architecture Design Document
Solution Architecture
Solution Architecture is much more mature across the different organizations even though it’s actually a lot younger than Enterprise Architecture. This is due to various reasons such as more usage, and more practitioners, but above all, it’s much more concrete or specific, fact-based. This makes it also much more useful.
I have done a number of solution architectures. Here is an example that showcases my design for an enterprise-shared service as an internal REST API microservice wrapper over a vendor-provided service for online identity verification to fulfill Canadian Anti-Money-Laundering (AML) banking requirements. Things to note:
- The first half of the document explains in detail the business objective and purpose of the solution.
- The second half shows a detailed technical sequence of a modified OIDC flow including all the main REST API calls, internal and external, with their parameters and return values. It includes code specific to the solution.
- The second last diagram shows the E2E AML business process and how this service fits technology and business-wise within it.
Example – Verified.Me Solution Design Document
Architectural Assessment
I have another architectural artifact that shows my ability to look critically at the client’s architectural practice, see critical problems, and propose solutions to these problems.
I worked for a banking client where the most common pattern for design was ‘copy and paste’ an existing app into a new namespace. This was done because of the tight coupling between the front end and the back end, where the back end drove the web page flow and content. This practice itself was based on a misunderstanding of the application and its core business purpose. The architecture team and the business users thought the application was based on a specific flow of the screens, and hence, any new “flow” required a new application in their minds. I point out that this is simply a misapplication of domain-driven design (DDD) concepts to an unsuitable domain, a domain, with many variations of the same business pattern.
In the end I proposed a brand new single reactive design to replace all the existing applications with each layer independent of any other layer and driven by event-based messaging in the back.