The Secret to the successful Cloud is Commoditization and Democratization and the resulting Governance

Hi,

It's been a while since the previous post. I've been way too busy with all kinds of projects and initiatives.

One of these concerned a customer of mine that wants to venture into the Cloud. The reason for them is, mainly, reduction of costs. Or rather reduction of IT expenditure.

Upon analyzing the benefits of a Cloud initiative within the four walls of the data center already in use we stumbled across something completely different. A means of saving quite some IT budget without moving to the Cloud. But interestingly enough, the effort would also mean a better paved road to the Cloud.

Okay, done with all the secrecy. Let's lift the veil.

One of the problems my customer is facing is the fact that a lot of their compute resources are dedicated to fulfill specific business needs. Well actually, they're the needs of some people within the company.

As we found out, a lot of time, effort and money are spend on customizations of COTS (Common Of The Shelve) products. And as we went down memory lane, reminiscing, I learned that over the last decade many projects within the company were long term, strategic projects involving the implementation of large products. An ERP here, an HR system there, some BI with the DWH thrown into the mix as well. Some more initiatives like a true IAM setup had been concluded as well. Each of these projects were concluded as a success. Predominantly because they were backed by the senior managers and each of the projects had been implemented as gradual implementations instead of Big Bang implementations. Nevertheless, millions of Euro's had to be spend and are still spend on the resulting systems.

Another key reason why the projects were a success, was that the resulting systems fitted nicely within the business processes already in place, hence people hardly needed to learn a new way of working, so benefits were reaped almost immediately, albeit limited to just some optimizations due to automations. Not really LEAN.

The issue here is that the products, the services if you will, were customized if not already tailored, towards the organization. Although of the shelf, they were no longer suitable to be put back on the shelf. Interesting detail in this regard, is that in pretty much all these cases, the implementation projects were quite costly and took considerable amounts of time.

Also note that in many cases, these projects were actually failures and a lot of time and money was wasted, because of these customizations. I'm sure you've been in these situations or at least heard of them.

The issue here is that the customizability of these products define their usefulness in the enterprise. And their profitability for the vendor, especially its professional services group and its partners.Now with the advent of the Cloud and most notably applicative services provided through the Cloud, SaaS, customizability is the last thing you want. Why? Because economy of scale is what drives SaaS and the more customizations are allowed, the smaller the scale.

You probably noted that this post is not about SaaS perse, but about Cloud. Yet I am treating SaaS here specifically and will delve into the realms of IaaS and PaaS later in this post.

Just for your reference, when I talk about SaaS, PaaS and IaaS, I'm using the definitions of NIST as found in: "The NIST Definition of Cloud Computing". This is important to know, as there are many definitions out there and some are conflicting with the one I'm using in this post.

SaaS - Software as  a Service

So far I hope you'll agree, it is in the SaaS provider's interest to standardize as much as possible in the service offered. Meaning that the functionality provided and the context in which it should be used, typically where in a particular (business) process and how in that process the service should be called. In addition, the SaaS provider will limit the customization of the offered service as much as possible ensuring that diversification is as limited as possible. Why? Because this will trigger the economy of scale aspects of the Cloud that are so beneficiary for the SaaS provider.

And obviously for the SaaS consumer as well. Economy of scale at the provider's end translates into lower costs of the service at the consumer's end. And isn't that what we want when going to SaaS? Yes, it is. But in addition, one thing to remember and take into account as well is the fact that more of the same results, typically more of a high quality. Less is easier to control, maintain and support. And with more consumers it will be more enticing for the provider to keep the consumers happy. Happy customers drive marketshare to a significant extent.

Concluding, standardization of services provided as SaaS is a key aspect of SaaS. There's no way around this. But that means that the service will more and more become a commodity. It has to be, because a commodity is something that is in widespread use, meaning that as a SaaS provider, you have a lot, preferably as many as possible, consumers. Here's your economy of scale again.

So there's your commoditization of the service and with that, you'll lower the cost of the actual service. Up to a point where you can offer it for free for a limited time. Get your consumer hooked on your service. An initial free service, or one with such low entry costs that it's almost free allows everybody and their mother to subscribe to the service if they wish to do so. And there's your democratization.

Back to the SaaS consumer end as the afore mentioned is more concentrating on the provider end. The consumer will be required to use the service as the SaaS provider intended it to be used. There's some room to customize the service to fit within the existing environment, but that's limited. The days for huge customization projects are over. This is not a problem, because the service is considered a commodity, hence it is most likely based around best practices, organically grown from market presence of the service. So the individual users will be happy to adjust their working patterns because the new patterns, if any, will feel as a natural fit. Mind that typically it are not the end users that want the new product to be customized to fit the needs of the organization, it's management. Those that should govern the process, not those that should work the process. With the democratization of the service, it will be those that are willing to change when needed that will consume the service.

As such, the provider and the consumer are benefitting from the commoditization and democratization of the SaaS offering.

IaaS - Infrastructure as a Service

Okay, so let's talk infrastructure. What about infrastructure and how does this relate to commoditization and democratization? Again it's economy of scale that's key.

Cloud offerings are interesting to the provider, including IaaS providers, because of the huge amount of customers they have and the standardized offering they provide and the streamlining they can achieve with their processes because of this. Because of the standardization, they can automate most of their processes. The investments to do this, which are huge most of the time, are warranted because the cost per piece are low. Here's your economy of scale at work, again.

For this to work, the IaaS provider will standardize on the hardware that will be used to build the cloud offering on. Typically this is the hardware of the quality "as cheap as possible". It's the commodity hardware everybody can buy. The off-the-shelve hardware. Again, the cheaper the boxes, the more can be bought. The more are bought, the more customers can be hosted on the infrastructure. The more customers, the lower the costs per customer. And again, here comes the democratization part; lower costs means that more people can start leveraging the cloud. But as with the SaaS offering, the true benefits are in the economy of scale for both the provider and the consumer.
As already pointed out, the provider clearly benefits of the economy of scale, but predominantly because it strengthens the position in the marketplace.

For the consumer, the benefit is in the lower costs and because of the fact that you can buy the service, or rather subscribe to it with a pay per use cost. In most cases there's a monthly fee, to cover the administrative costs for having you as a customer, but beyond that, you pay for what you use.
From a consumer perspective therefore it becomes critical to also be aware of that your chances for customization are limited, extremely limited because you can only get what's on offer. And what's on offer is highly standardized.
There's an added benefit of this, namely the fact that you're required to standardize and therefore you can standardize on your support efforts for those systems that are 'in the Cloud'. Because the service you're subscribing to is IaaS, you will have to support the OS and everything on top of it yourself. By being limited to just a few options, provided by the provider, it will be relatively simple to move to an outsourcing model for your maintenance and support efforts.

The democratization of the infrastructure because of the Cloud is a problematic aspect of the Cloud in case you, as a consumer, are not yet mature enough to have the right governance in place.
To understand this and appreciate this to the fullest, you need to scroll back to the SaaS discussion. The democratization of the infrastructure through the Cloud initiatives all over the globe, means that everybody and their mother can just create a server in the Cloud, provided that they have a credit card. All Cloud providers will provide you with a basic server, limited resources and a default albeit fairly secure, OS installed on it.
Without the proper governance in place, your environment will become uncontrollable as servers will be added to it that are unknown to your support staff, running critical applications before you know it and integration requests will pop-up as you read this blog post. (Also refer to my post on this topic at: Is there a market for the Cloud in the world of Corporates?.) Complexity will not come from an ever increasing level of heterogenity, which shouldn't be an issue at all. This will be limited because of the limitations of the Cloud provider. The complexity will be a result of not knowing that there are servers in your environment. This can only be prevented when there is proper governance. This is where you should use governance to enable and defintitely not to restrict.

PaaS - Platform as a Service

Considering you've already exerted the effort to read until this point, I'm sure you'll appreciate that I'm concluding with the platform as a service by saying that it's just the same as IaaS. But then again, it's not.

PaaS, the platform as a service, is where the Cloud is starting to put some software on your server. True, IaaS did put an OS on the server, but the Cloud provider wouldn't support it. That was yours to do. With PaaS this is not the case at all. You subscribe to a platform so the provider will deliver it. This can be as simple as just the OS, so the service you'll subscribing to is a server with a managed OS on it, or it goes as far as a complete software stack, completely supported and maintained by your PaaS provider. An example of this is Amazon's Elastic Beanstalk (EBS) offering, an offering where you do some clicking and presto you get a server running completely configured for you an Apache Tomcat instance. Fully load-balanced and all.
And here again, you probably guessed it, the economies of scale are key. By controlling the full software stack, the PaaS provider controls what is to be supported, meaning that the PaaS provider dictates the standard. By complying to this standard, as a consumer you benefit from the scale the provider is managing. Thus lower cost. By this model, the platform is commoditized by the PaaS provider and because of the low cost, the platform is democratized.
Now what does this mean. Well for one, if you look at the example of Amazon's EBS offering, it means that a few standard platforms for web-based applications are provided by Amazon as a commodity to its customers. Where in the past, it wasn't really trivial for an enterprise to host a fully scaleable web application facing the public internet as setting up a fully load-balanced environment with all the security constraints in place, based on best practices not only required skilled staff to architect and later on operate, it also required significant investments in order to also be able to provide the necessary resilience. This has now become an almost trivial exercise. You just click on some buttons that you want a Tomcat based environment, or Microsoft IIS based for that matter, and if needed including a database and just a few minutes later you get your environment. All up and running, first year free of charge and ready to roll. With all the scaling out of the box, and totally restricted.

From a PaaS provider perspective it is clear why it is necessary to standardize and restrict. But the understand it is a double edged sword as standardized environments lead to lower TCO (Total Cost of Owndership), but that as a result leads to the ability to commoditize the platform and democratize it.
From a consumer perspective it should be obvious as well that these offerings can only lead to... well that actually depends on who the consumer is. Considering the individual, commoditization and democratization are huge benefits as they result in less effort and budget needed to get the same results faster. It has never been as simple and trivial to deploy a web based application on the internet with full resiliency and scaling capabilities, provided that the application can handle this. From a business perspective, i.e. the business user at the PaaS consumer side, the same holds true. But there's the issue of operationalizing the business services. That can become tricky, but this is where the PaaS part helps. Maintenance and support are handled by the PaaS provider.

There's actually something to be mentioned on this topic, that I will cover in another post, because maintenance and support are far from a given in a Cloud environment.

The serious issue here is with the CIO, or the IT department in general. The standardization is with the PaaS provider. This would be a nice time to read my post on heterogeneity and homogeneity. Basically, what it says is that it is virtually impossible to have a homogeneous environment and it is wasted time, effort and money to strive for this. And although the PaaS provider will only provide a limited set of options when it comes to the P(latform) as a service, the individual consumers can still run havoc with your standardization efforts, because of the commoditization and democratization.
The issue here is that from the perspective of the enterprise as the consumer it goes without question that it should be accepted that the PaaS offering is in fact a commodity and practically everybody can subscribe to it. From an IT department perspective, this should be embraced as that will mean that internal processes and procedures as well as policies are in place to support the virtually effortless integration of PaaS offerings in the 'legacy' environment.

Dare I say it? Yes! Once again, it all boils down to governance. And with a Cloud component in an IT landscape more so. Why? Because the Cloud makes the specialized tailored solutions of yesteryear a commodity of today. Accessible to all. literally all. And therefore, one can't control through restriction, through closing down, but through enablement, i.e. opening up.

What experience learns...

So here's the sad part, really. Most of the enterprises I've been. Most of my clients facing this situation are not yet ready to handle this. They so desperately want to 'do Cloud', but they just don't have the governance in place.
This is typically in the area of architecture (there's no architecture governance), maintenance and support (still focusing on traditional maintenance and support schemes) and running IT in a multi-dimensional silo'ed fashion (strict separation of network, infrastructure, application and business instead of seeing IT as a combination of man and machine solution, strict separation of a project organization and a operations organization resulting in an 'over the wall' mentallity, strict separation of analysis-design-implementation phased approach to new developments).

Well, as usual, I'm really delighted you've come this far and took the time to read this whole post. I understand that it's once again a very long post. Probably loosing coherence every now and then. It took me about a week or two to write it up. Which is never a good thing for a blog post.

As always, drop your comments in case you see things differently. It's the different points of view, from which we learn the most and from which we can complete our picture.

Iwan

Oh No!!! Our environment is homogeneous, we are doomed!!

Abstract: 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.

Hi,

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 ever want to cut costs. They'll tell you to reduce costs because that's what the accountants say, what the CFO dictates, 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 wouldn't ask for more new business (projects) to be realised 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 opportunity to improve profit numbers on the balance sheet and it is more fun and it is more long term.
IT therefore should not focus on being less costly, instead IT should focus on being more business 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 it. Choose heterogeneity as an architecture principle. Assume that nothing in your environment is standard. Design your solutions based on this, define your strategy based on that realisation. Unlike other assumptions that make an ass of you and me, this is a safe one to make. It's safe to assume that nothing is standard forever.
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 standard will no longer be. Hence, everything is or will be legacy. In the near future. An old saying in IT operations is:

Legacy is what we have in Production.

Not feasible? Not doable? Not wanted? Well, have you ever seen a fully standardised, homogeneous environment? I'll give you some slack and only ask you this question to be answered for only 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 child that is always misbehaving but still it is your child so you love it, no matter what. But you can't wait until she's 18 and on her 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 facilitate 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, in order 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.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect


The text very explicitly communicates my own personal views, experiences and practices. Any similarities with the views, experiences and practices of any of my previous or current clients, customers or employers are strictly coincidental. This post is therefore my own, and I am the sole author of it and am the sole copyright holder of it.

5 Reasons why TOGAF Certification could be a waste of your time

Okay, first of all: TOGAF is an acronym and I have strong feelings about acronyms. See my previous post on this Dogma of Acronyms.

With that out of the way, I also want to make clear that I am a great proponent of architecture and I think that understanding, that is Understanding, of the principles behind TOGAF and how to apply TOGAF within an enterprise environment is very useful.

It's just that certification is a waste of time. And in this post I will provide 5 reasons in an arbitrary order, why it's a waste of time. And because the order is arbitrary, I won't number the reasons so you'll have to count them yourself.

• Enterprise Architecture is an activity and todo it right, to master this activity, takes practice. As the proverb goes; Practice Makes Perfect. Certification is a hoax from this perspective, since it doesn't require you to be an experienced architect that knows the specifics of TOGAF. It requires you only to know the specifics of TOGAF. Since the role of the architect is the most senior role in IT, in my humble opinion and many HR managers agree with me, being certified should take this into account.
• TOGAF covers to broad an area to be applied within an enterprise. TOGAF covers the complete enterprise and although I completely agree with this coverage, leading from business aspects all the way down to IT through Organization etc, this is hardly applicable in an enterprise. Typically TOGAF is done by IT people. Huh? Yes, by IT people, and this is due to the fact that the role of architect is typically an IT role. And on top of that, it was invented because there were too many senior IT people that sucked as managers. So in order to get them higher pay grades they became architects. And yes, there's the irony, architect are supposed to manage projects and programs on a technology level. Uhm, uh... what's happening here?
• TOGAF is based on best practices, models and notations. So it means absolutely nothing unless you fully understand your enterprise, its current state, where it wants to go and so on. Just like ITIL, being certified has no value to the company you're working at, what has value is you understanding what's good for the enterprise and what's not. Which means that you need to be engaged not certified. 
• Being an architect means you need to be able to communicate, and more importantly, you need to be a sales person. Being a successful architect means that you can sell an idea and in contrast to many sales people, also need to ensure delivery once you've sold it. As the architect is the most pro-active techie in the enterprise, having a long term view and a solid idea as to how to get there with steps that need to be taken immediately, you have to get that mindset. No TOGAF course teaches you how to become a great sales person, so don't think you'll be a certified sales person either.
• Everybody who wants to be an architect and has some time available gets TOGAF certified these days. Darn, I was thinking about it myself when it seemed as if my contract wouldn't be extended. Very similar to the Java certifications in 2003/2004 when the IT job-market was down in Europe. Unlike that time, I see that at interviews CV's of those that are TOGAF certified are scrutinized for experience that matches the claim of being knowledgeable because certified. I think that having done the training but not getting certified is better than being certified as it shows that you got the theorie, but don't claim the experience.

Unfortunately not many HR managers understand this and allow IT managers to send their staff en-masse to TOGAF training. Staff being certified are returning to enterprises that are not ready for enterprise architecture. Hard cash spend on training but no cash spend on following this through. I think for any company it is better to decide on a strategy and follow up on it from the various manager levels and support it by sending the right people to the right training.

In  my humble opinion, Enterprise Architecture and consequently all methodologies related to it is too mutch of the good stuff for many enterprises. For most of the enterprises I encountered. It's a maturity thing and as with us mere humans having to go through infancy, childhood, puberty before becoming adults, if at all. The same goes for organizations.

So dear HR manager, think first if your organization is actually mature enough and needs Enterprise Architects before you send your best resources to training and certification.

It is my experience that you should send your staff to training to improve your enterprise, and to certification to improve your staff. And at all times, you send them to training and certification if you choose so, that is relevant... in the short, mid and long term.

As always, thanks for reading this post and please comment when you see it differently. Diverse opinions make for clearer perspectives.

Iwan