Gabriel Morgan knocks one out of the ballpark in this blog post that traces the connection from Business strategy through business process to applications, data, and hardware.
Highly recommended for anyone who is an Enterprise Architect or aspires to being an Enterprise Architect.
One aspect that Gabriel didn't address is Application Portfolio Management. I'd like to wax a little on that subject.
Every Application costs money to own. If an application ABC stores its data in a manner that is difficult to integrate, and you need to write another application PDQ that moves data around and transforms it, and even another application XYZ that is used to handle the data quality issues and workflow that results from all that data manipulation, then the cost of ABC includes the cost of owning and maintaining both PDQ and XYZ. That overhead can get pretty expensive, pretty fast.
Application Portfolio Management is an IT practice that views the list of applications in operation within the bounds of an enterprise as assets with individual costs and business value. This methodology helps to identify applications that should garner further investment, while identifying applications that should be kept running (maintained) without further investment, or even retired.
One valuable activity within Application Porfolio Management is to scan the portfolio looking for redundancy. Let's focus on this one activity.
The degree to which an application is redundant with other applications is a useful indicator of whether the business is likely to benefit by retiring or trimming the features of one application in support of another. In other words, if application ABC has four features, and application DEF has four features, and they overlap on two, then you are paying for eight features, but you get only six (plus the possibility that you have to add features in another application in order to reconcile the data from both). A good simplification activity might be to add two features to ABC and turn off application DEF. (this is a wild oversimplification, but it will do for now).
The problem comes when you have more than a few applications in your portfolio. If you have 10, or even 100, then you can probably compare each application with every other one, looking for overlaps. But if you have over 2,500 applications, as we do, then the cartesian product becomes absurd. We'd be talking about making over 6 million comparisons. Assuming each comparison takes two days to do (which would be about typical), then a team of 50 people would take about 1,000 years to complete the task. Hmmm. That's not gonna work.
Solution domains provide a mechanism to reduce that comparison overload, making an attempt to scan for redundancy feasable. Because each domain contains a set of "system features" that a business person can understand, then it is not difficult to map each application to one domain. (Technically, one application will map to one 'primary' domain with relationships to other 'secondary' domains as needed). Once you have done this, then you can take your porfolio, break it into 82 parts, and get much smaller groups of applications. Divide and Conquer.
Assuming that our portfolio were to map evenly over the solution domain taxonomy (for the sake of public discussion), then we'd have about 30 applications in each domain. Assuming that about half of those were clearly not candidates for further investment, then we would only need to compare, in each domain, 15 applications with one another. Each domain would take a couple of months for a small team to analyze for redundancy. Entirely do-able.
In addition, you can choose to only analyze one or two 'core' domains to start. That will allow you to prove the process works, establish value for your simplification efforts, and produce an action plan that people can use to measure return on investment.
And what change would that require in Gabriel's diagram? Currently, he has a single line from Application to the services within a solution domain. I'd add another line, from Application to a new sub-box within Solution domain called 'Feature'. This is a seperate mapping that is not useful for service management... but for APM, it's priceless.