Traditionally, IT organizations have divided all of the services they deliver into three layers: the infrastructure (infrastructure as a service), platform (platform as a service), and applications (software as a service). But these layers are an artificial construct that's not very useful anymore because the real world has become much more complicated.
So what can you do to manage the ever-increasing complexity if you can't rely on the simple three-layer model of services? Instead of inventing a solution, look at how other businesses manage similar kinds of complexity. Here's the why—and the how.
How the manufacturing sector manages complexity
Consider the manufacturing industry, where everything organizations deliver out of the factory is managed as a product, and products have dependencies. The car is a product. The engine is a product. The windshield is a product. Even car rental is a product (car as a service).
A typical car has thousands of components, and most of them are considered products on their own. Some are developed and managed in the same factory, while others are supplied by other factories. So how do you manage that complexity?
Consider what you deliver as a product and manage that as a product that has dependencies on other products and that can be consumed by other parties. That's the taxonomy to use, rather than saying IT must deliver apps that depend on the platform, and the platform depends on the infrastructure.
This means that across all your products, you have a very complicated dependency map or set of dependencies, and you need to ensure that you understand what depends on what. And that dependency is more complicated than saying this application is running on a platform and this platform is running on that infrastructure.
You have to consider every service you deliver as a product, and you need to understand the dependency across all your products in your enterprise.
Another way of looking at complexity is to ask: Is IT spaghetti or lasagna? Unfortunately, the reality is that IT is spaghetti, not lasagna, because it's not neatly layered.
Map out the spaghetti
If the reality is that the IT world is spaghetti in nature, then you need to focus on controlling that spaghetti. You need to figure out what the actual connectivity is among all of the varied products you have—and that's the product dependency tree.
Once you do that mapping, you'll start to understand certain things, such as what your risk of failure is. Something fails for two reasons: either the application itself fails, or something on which it depends fails.
Unfortunately, those dependencies are often not well mapped out. But if you understand what the application depends on, then you can see if you are depending on something that is not stable.
A high-availability app may not really be
For example, let's say you have a service with high-availability requirements, so it needs to run 24/7. And it depends on an underpinning platform, say Kubernetes, that is also designed to be highly available 24/7, with a lot of redundancies and nodes to deal with failures.
But when you do that dependency mapping, you discover that the application also depends on a payment gateway service, but that payment gateway service is not designed for high availability. It's guaranteed to work only during business hours.
Then, suddenly, the entire application is no longer highly available. By understanding that dependency, you can start making good decisions about how to improve your situation.
In addition, if you want to change the application, you need to understand who's depending on you, so your services should be mapped out. That way you can ensure that if you make changes, you still serve the people or the products that depend on you.
Understand your dependencies
If yours is like many organizations, you recognize that the true dependencies are complex. The way most IT groups deal with that today is that once something is deployed, they try to discover all the dependencies and them map them out. This is meant to ensure they can track them so that when they do change management or there are faults, they can report them correctly.
You need to do that at a strategic level to understand your essential products and the dependencies among those products.
Going back to the manufacturing analogy, no manufacturer would build a car and then, before handing it over to the customer, take pictures of all the car parts to document what was delivered in case the buyer has issues. Rather, manufacturers have bills of materials and sets of blueprints in place before they start delivering cars.
You need to understand the essence of your entire enterprise and how it's connected.
As your organization becomes digital, it's driven by digital systems; the enterprise architecture is about how these things are connected and about delivering products and services to the business. The enterprise architect ensures that all the bits and pieces you put in place to run your business actually make up something that is manageable and useful.
It's time to remodel
Another reason for the traditional IT services model is accounting. This gives the chief financial officer a way to track IT spend. Typically, the CIO organizes IT into an application group and an infrastructure group. Again, this is not a healthy structure.
Product orientation allows for much better financial control, since you can better propagate and calculate cost across the product-dependency hierarchy. This provides a much more fine-grained understanding on where you're spending the budget.
Forget about the differentiation between infrastructure, platform, and application layers—that's an old paradigm that's no longer relevant. Instead, treat every service you deliver as a product. That means you need to understand the dependencies across all of the products in your enterprise. If you don't do these two things, then you'll be stuck in the old world and you'll never be in control of your digital business.
If you're not comfortable with how to deliver and document the enterprise architecture, it's time to improve your skills. One way to do that is by learning the language that can be used to express the architecture and associated product dependencies.
So how do you get started? Try ArchiMate, an open and standardized enterprise architecture modeling language that allows you to model out these kinds of dependencies.
Keep learning
Get up to speed on digital transformation with TechBeacon's Guide.
Download this free IDC white paper, "Enabling End-to-End Digital Transformation".
See IDC's Futurescape: Top 10 predictions for digital transformation.
How important is digital transformation to your org? Take our survey and find out how you stand next to the competition.
Thinking of making a change? TechBeacon's Careers Topic Center provides expert advice to prepare you your next career move.
