Lately I've been involved at a number of discussions regarding application replatforming. The main reason for the replatforming is to make the environment more homogeneous. The reason for this is that there is an overall perception that this will allow for a lower TCO of the complete IT landscape. Which is, or seems to be, the goal of many architecture initiatives lately.
I, unfortunately, have to agree with this. To a point. And yes, no typo there, I do state that it is unfortunate. I'll get back to that later.
I agree to a point, because homogeneity is the result of standardization and when we talk about a homogeneous IT landscape we mostly think about far reaching standardization of the IT assets. Typically the infrastructure, operating systems, middleware, database (I don't consider databases to be middleware), and even business solutions like CRM, ERP and the likes.
The more you can standardize here, the more of the same you'll get in your environment and therefore the more benefits you'll get from the economy of scale as a result. As such, economy of scale results in lower TCO as typically you'll be able to do more with less, especially in the area of support and maintenance, i.e. the operation. Add to this some form of virtualization and you'll be utilizing your resources, computing resources that is, more efficiently, meaning less hardware investments.
There's another benefit here, that has less to do with economy of scale (and arguably the TCO) and more with standardization and therefore quality. This is the fact that when you standardize on your assets, you can also standardize on your processes to maintain them once you've reached a high level of quality and more importantly, the people you have to support your environment need less (diverse) training and can achieve a higher level of quality by experience. Ask any SysAdmin how long it took until they felt really comfortable with supporting an OS, and they'll mention years of experience.
Take it up a level and you're in the realm of middleware and databases and this is where you can really lower the TCO by closing strategic enterprise license deals with middleware and database vendors.
So where am I getting at you might ask yourself. Well, that's easy. All the above is why many if not most of the enterprises and SMB's for that matter, do standardize and do want to get to a homogeneous IT environment. I've been there myself as well. Evangelizing the mantra of homogeneous, standardized IT environments.
The issue the issue here is that we do all this work out of reducing cost. And the reason for that is to improve profitability. And this is because IT is most often seen as a cost-center within and enterprise just like staff, so IT reduction, just like staff reduction is something you do when times are challenging and profit is hard to be made. This is because the accountants dictate this. Look at the books, where are the most costs on the balance sheet, cut those and you're done. Awesome...ly narrow sighted.
What we tend to forget is that IT, just like staff, is an enabler. An enabler of revenue and therefore an enabler of profit.
Let's think about that for a second, forget about TCO for convenience because I am aware of the 80/20 rule when it comes to IT expenditure. So instead of thinking of IT being a cost-center, consider it to be a business enabler. Ignore the screamings of accountants and listen to the mantra of the business people. Strangely enough, they hardly want to cut costs. They'll tell you to reduce costs because that's what the accountants say, what the CFO therefore says, what the shareholders say, not because they think that's the right course of action. Really, they don't. I'm 110% certain of that because otherwise they would ask for more new business projects to be realized and instead would order IT to execute projects to reduce IT expenditure.
So those business people in the enterprise want new business projects, pursue new business ventures, address new markets, jump on band wagons. It's all "spend, spend, spend". Why? Because they want more revenue, because that means more chance to improve profit numbers on the balance sheet and it is more fun and it is more long term.
IT therefore should focus on being less costly, instead IT should focus to be more enabling. And trust me when I say that a homogeneous IT landscape is less enabling than a heterogeneous IT landscape.
Do you get my 'unfortunate' at this point in the post?
Let me elaborate. First of all, heterogeneity is evil, unless you not only accept it (because it is inevitable!), but also embrace. Choose heterogeneity as an architecture principle. Assume that nothing in your environment is standard, build for it, define your strategy based on that assumption. Unless other assumptions that make an ass of you and me, this is a safe bet. It's safe to assume that nothing is standard.
Thing is, everything is always changing, everything is always in motion so nothing can be standardized without the need to revisit your standards and as such what once was standardized will no longer comply. Hence, everything is or will be legacy. In the near future.
Not feasible? Not doable? Unwanted? Well, have you ever seen a fully standardized, homogeneous environment? I'll give you some slack and only ask you this for just the OS level. Forget about the layers underneath and forget about the layers on top of the OS. It's just not there, there are always different versions of the standard OS. And no, they're not the same because if that would be true, there wouldn't be the need for a difference.
Okay, so adopt heterogeneity and embrace it as a son that is always misbehaving but still it is your son so you love him, no matter what. But you can't wait until he's 18 and on his own. (Yup, I've blogged about off-spring and the need to be able to let go in a previous post)
This means that you need to learn how to live with it. Your processes of supporting and maintaining that IT environment need to allow for heterogeneity.
Why was that again? Uhm, I don't think I covered that, but if you still can't guess, think back of the IT being more enabling.
The trick here is that you need to understand that the IT is servicing the business, which means more revenue needs to be generated as part of the IT endeavors. So if the business wants something, IT needs to deliver it. Without question. IT answers, it doesn't question. It also answers truthfully. And yes, this not only implies, but explies (if that were a word) that the environment is heterogeneous and will become more and more heterogeneous as time moves on. Which is awesome, because every request of business is delivered.
It's going to be a mess, unless you embrace heterogeneity. When you don't, when you require homogeneity, demand it in fact. Question the requirements of the business, actually be so arrogant as to know better what the business wants than the business itself, than you will not be able to deliver on every single request of the business. You'll be less, probably a lot less, than adequate and you'll be less of an enabler.
What you want, or rather what you need to be successful is a heterogeneous environment. There is no place for homogeneity in today's enterprises.
Really? No, not really. We're almost there... You can only do this when you do architecture within your company. I mean define conceptually how your environment looks like, model it. Remember it is only a model! Ensure that you have the right governance in place to apply this model. Govern.
Realize that in the above, I never stated that this is related to IT, it is related to the enterprise, however small it is. Also realize that nothing in there is fixed, in fact, all is subject to change. So don't consider the model as dogma (see a previous post on the topic of dogma), don't lay down a doctrine.
Make sure your conceptual model is backed by a logical model which is governed. Again, there's nothing specific IT in there. It's the enterprise again that is modeled on a logical level. Also remember that logical means that the model is logic to all stakeholders.
Easier said than done? Well, I would say, easier done than said as long as you do architecture in the right order. Meaning that business requirements dictate architecture dictates technology dictates tools dictates implementation. Most of the times we do it the other way around... that's why you end up with easier said than done, as that is also the other way around.
Ah, yes, there's the CFO and the shareholders who are kind of important in the eyes of many, and in any case they have that pile of money you want a piece of. And they want cost reduction, maintaining revenue, increase profits... This is where you want to standardize, but in an abstract way. Which means, move those parts of your heterogeneous IT landscape that are costly out, away from being your responsibility. In other words, where it makes sense, move your IT to the cloud. Again, don't make this doctrine, but move those parts that make sense to you to the cloud (read my position on the cloud with respect to enterprises in a previous post). These are the systems that you need elasticity in some form to be achieved, where you need certain facilities (security related, availability related, connectivity related) to be at a level where you just can't handle it yourself. This won't be an issue as long as you've been accepting and embracing heterogeneity. Because from that perspective, the cloud is just another something non-standard.
By moving to the cloud, you can actually benefit from the economy of scale... the scale of somebody else. And wasn't this the proposition of making things homogeneous? Of defining standards and standardize? As it is with cloud, it only works with the cloud provider because he standardizes. Not so much on getting a homogeneous environment but on the way you perceive that environment. And since you're not (completely) free about what the environment looks like (with IaaS more than with PaaS more than with SaaS more than with BaaS), you're forced to think about how things work together. About how the applications that meet your business needs provide these and enable your business to increase revenue. And with the limitations of the freedom you have on this, you're bound to standardize on a conceptual level.
So in short:
- Homogeneity -> IT is a cost-center
- Heterogeneity -> IT is an enabler
I hope this post has made sense, or at least has provided to you a different view on standardization in IT. As always, you're more than welcome to provide your insights. The more views, the more perspectives, the more complete the picture.