The Americans have a saying - “it's like motherhood and apple pie”. When an American manager says this, it's not actually a good thing. It's their polite way saying “Yeah, you've given me something abstract that everyone can agree on in principle, when what I need is something that I can make a decision about.”
Enterprise Architecture can face the same problems. In theory everyone can agree with the idea of aligning the provision of IT to the business. In theory everyone likes the idea of mapping processes to the applications that support them. But past experiences usually mean that at best executives are wary that nothing will come out of such efforts, and at worst they see it as an expensive waste of time and effort.
With that in mind, I'm going to spend the next few posts outlining five specific, concrete use cases where modeling dependencies provides value. In each case we'll start by describing the business problem. Next, we'll formulate a question. I'm a strong proponent that modeling, and especially business modeling, provides value by answering questions. If we adopt this as a principle, then we can usually focus the discussion around any model or report by identifying the question or questions that this model addresses. Last of all, I'll describe how a model can address the question.
So, the first case that we'll consider is the issue of environmental software levels. Which is to say, an airline is going to have a reservations system and a loyalty platform and so on, and a bank is going to have a fraud detection system and a compliance system and so on, and a telco will have a voicemail system and a bill record system... but all of these systems run on Windows, or AIX, or z/OS... or various other platforms. And they'll often use a database – Oracle, or SQL Server, or MongoDB...
Unfortunately, all of the above software packages have different releases, and different patch levels... and software vendors have a habit of decommissioning support for old releases, so the question becomes, how to know when a vendor of environmental software will decommission support for a release level that one of your current packages depends on?
Or to give the elevator statement of the problem: For each of our user-facing software, what environmental software can they run on, what environmental software do they run on, and when does support run out for these environmental software levels?
This is where it becomes useful to model the dependencies between the system software and the applications; once this is done, any decent modeling tool will allow planners to ask the question: for application X, what are the supported environmental software levels for that version of the application, and when does the vendor support end?
There are a couple of implementation details to be aware of, however. First, vendors often have different support levels, which will end at different times. Second, the precise levels of support will differ from vendor to vendor. Unfortunately, the best way to address this will vary depending on the capabilities of the modeling tool being used.
Last of all, this does involve an investment of effort to collect the support lifecycle information involved. For this reason, it might be that the organization decides to only perform this exercise for their mission critical applications. As always, it is necessary to balance the expected return from modeling with the expected cost.