Let’s review two indispensable tools for any self-respecting Enterprise Architect (EA): Inventorying and Modeling.
Both mechanisms provide unique advantages for handling complex IT ecosystems—and both present limitations which only the other can improve.
EA inventorying, as represented best by IT Inventory Management providers like LeanIX, utilizes configurable fact sheets to build a taxonomy of an organization's applications and technology. It identifies and comprehensively defines all moving pieces in a modern company’s architecture in order to answer one simple question: is this helping to support my business in an efficient and cost-effective way?
Of note, strategic inventory-driven EA practices regularly include the following:
- Application Portfolio Management (APM): A transparent summary of a company’s every application (licensing terms, version dates, etc.). APM focuses on organizing software assets in a manner analogous to financial portfolio sheets.
- Application Redundancy Analysis: A substantial size of most IT budgets are based on the maintenance of applications which offer no clear business value. Application redundancy analysis uses real-time data sharing to eliminate this waste.
- IT Risk Management: Does an application portfolio adhere to security standards? Which IT components are out of the lifecycle and most likely to interrupt business? Is an IT network based at all in hazardous locations? IT Risk Management uses dashboards and alerts to help decision-makers answer these questions.
These EA inventory approaches are especially necessary in digitally mature global organizations. As market forces push efficiency standards to new heights, LeanIX-style inventory solutions with on-demand analysis and reporting functionality are frequently adopted to support core management strategies. Finance and Business Development officers now often look at IT landscapes to locate savings and increase profits—and they do not want to wade through a swamp of disorganized applications to do so.
The benefits of inventorying for EA professionals is thus clear: it’s expansive; it’s collaborative; and it’s fast. So why, then, would an EA ever need to employ modeling?
To properly understand, consider that the underlying mandate of Enterprise Architecture is to engage in wide-ranging evaluations of any and all ways to manifest development strategies. What is the system currently doing; what is it supposed to do; and what procedure will make it happen? However, no matter how brilliant a formula for improvement is discovered, it is all for naught if the implementation strategy can’t be expressed.
A modeling diagram is the way to visually communicate one’s EA solutions in digestible ways.
It is commonly broken down into various categories:
- Use Case Diagram: A way to illustrate the steps required in an enterprise to achieve a goal. Use Case diagrams are intended to summarize and introduce relationships in an operation. For this reason they are often kept simple.
- Software Modeling: Software architecture modeling is the complex mapping of all components in a single piece of software or a computing process. Used to formulate and plot engineering designs, its plans are typically much more detailed than a Use Case diagram.
- Data Architecture Modeling: Data Architecture Modeling aims to illustrate the very ways in which an operation can and should store its data. In particular, it creates highly involved plans to help designers build superior IT infrastructures to more effectively receive, back-up and transfer data.
Each preceding category of EA Modeling is often told with a system of texts and symbols known as the Unified Modeling Language (UML). UML is a language used worldwide for theoretical decision-mapping. Its widespread utility and scrupulous nature is exactly why some enterprise architects require UML-based services to work in conjunction with Inventory Management.
We can look at it this way:
"Modeling for conception;
Inventory for maintenance.
Both for success."
So how can we achieve this in an universal way, across the entire enterprise?
How Inventorying and Modeling work together
Image 1: View of how LeanIX´ inventory works together with a modeling tool.
Ideally, we can use a tool like LeanIX to get an overview of everything that is happening in your IT-landscape. In the example above, we can quickly see which applications are being used by which business capabilities and in which regions. In this particular view, you can see what applications are being planned, which are active and which are end-of-life.
We see that the application "CoA" is being planned to be implemented in the finance department in Australia. But the details of this application (which elements will be used, how they work together, if the object is a string or a decimal number...) can be done in a modeling tool... and then for example attached as a document to the application in LeanIX.
Image 2: View of the application CoA with the detailed data model attached as a document at the fact sheet.
So what does this mean? Can one exist without the other? I think not. If we only look at things at a granular level, we lose sight of the big picture. On the other hand, if we only look at the big picture, we will be unable to have the needed precision for an enterprise to work seamlessly.
Let's use another example to illustrate this.
Imagine that your company created an application, let's call it "HR Admin" to manage all HR needs. This application was created 10 years ago and optimized to run on Windows XP. Nowadays, the application renders very slowly on modern PCs and is not compatible at all with Mac. Also, underlying technologies that were used are now outdated and not secure anymore, meaning that the application is open for attacks from hackers.
In this scenario we have two important points:
- We need to be able to quickly identify all applications that are, for example, not secure anymore due to outdated technologies...and we need to see dependencies to the application... in the example below, Information coming from HR Admin is provided to numerous other applications, including "Payroll".
Image 3: Data Flow in LeanIX showing dependencies of HR Admin.
- We need to be able to tell our developers how the new application which will replace "HR Admin" should look like on a granular level... for example, it should run on the latest machines, underlying technologies should be the latest versions, and even things like that the monthly salary should be a number with no decimals and in US dollars.
Also, we need "HR Admin v2" to integrate seamlessly into our existing IT Landscape (for which we use point 1 to research what dependencies it will have) and make sure that it is compatible.
So, how do you manage inventorying and modeling at your company? Do enterprise architects overlook this entire process or is this responsibility shared amongst others?
Tell us more in the comments!