Let me spell out why Bimodal IT doesn't work

Summary

In short, in a Bimodal IT environment, both modes need to move at the same pace in order to optimise productivity of the organisation. Value is created by products in the hand of the user, not by parts on a shelf or piles of almost ready products. This means that unless all relevant information is exposed by the Mode 1 systems, the Mode 2 systems will adjust their pace.

There's no excuse to use Bimodal IT as an excuse

Bimodal IT is an excuse for those that just don't want to accept the fact that we live in a world where there's no one size that fits all and that's also a world where we need to live together instead of separately. So thinking that Bimodal IT might work is totally ignoring the fact that the old and the new together result in synergy, that the short term and the long term go hand in hand and that classic IT models like the ancient Change/Run division can co-exist with brand new DevOps way of working. We have to realise that in IT only in the binary system it's black and white, everywhere else in IT there're more than 50 shades of grey.

If you're a wondering about my view on Gartner's Bimodal IT model, you should read my post on it. It's available here.

Why this post? Because in the last week, although I've stayed home for a day and a half caught by the flu, I had several discussions with colleagues about Bimodal IT and unfortunately, they considered in an opportunity. Not an opportunity to bridge the gap between systems that have a short life cycle and those that have a long life cycle. Or rather, short and long delivery cycles. And to be completely precise it's about the time it takes to think of a new feature and deliver it to a user. One mode is considering long cycles, the other is considering short cycles. Or rather, one is assuming many features to be released over time the other just a few. Think about a core accounting system and its front end. Accounting doesn't change that much over time, possibly some compliance reporting, front ends change all the time. Browser changes, mobile devices, etc.

Back to my discussions. The most symptomatic was about "Bimodal IT is used as an excuse not to comply with the ancient and really seriously out dated processes in IT that are (to be) followed within this organization and I assume unwillingness to try to modernise the processes. By just simply referring to Gartner and their definition of Bimodal IT and stating that this is the exact situation at their organisation, some of my clients architects and project managers are implying that the processes only apply to what's running in the back-end and what they're working on, which is the front-end." [from my previous post]

Understanding the frustration

It's the frustration about ancient processes and the requirement to comply with them that is causing this excuse to rear its ugly head. Fine, I can see this and since the organisation doesn't want to look into this and adapt its processes to become a little bit more 21st century, I can only agree to look for every possible reason not to stick with the old ways.

But here's the catch. Well, let's wait for a second here. I had this other discussion on the same topic. Now the discussion was about that Mode 1 systems need to be stable because they're the core systems, forming the backbone of the organisation. Keeping in mind the adagium "Never change a working system" they should be kept stable at all times.
Unfortunately, these systems exist in an ever changing world, so maybe they don't change, their context changes. And because they are so important, after all they're the backbone of the organisation, when troubles arise, they need to be fixed as soon as possible. High speed and high quality. In addition, you want to address issues as soon as they arise instead of queueing them up and apply in large batches.
It's the general misconception of the dinosaur; When you need quality, you spend a lot of time testing. I'll blog on that some other time, for now suffice to state that time and quality are hardly related.

The catch

Than there was the catch. The catch being that Mode 2 systems are those systems that are changed very frequently. Possibly because a first iteration is brought to the user as soon as possible and new functionality added regularly. Possibly because a new idea is tested and dropped when failing or productised when successful. What most of these systems have in common is that they rely on Mode 1 systems, since that's where the organisation's biggest asset resides: Information. You don't want to change an organisation's information model too much, especially not when the information has been build up in years. Information from these systems are exposed, to be used by other systems, typically Mode 2 systems.
Mode 2 systems are new, by definition. They're implementations of never-thought-of-ideas, and therefore it is very likely that the Mode 1 systems do not (yet) expose the relevant information. Hence with the advent of the Mode 2 systems, the Mode 1 systems all of a sudden need to be changed, regularly, often, quickly, consistently. All the time maintaining a high level of quality.
There is no chance that Mode 2 people will allow the Mode 1 people to move at their own speed because that means they'll be moving just as slow. 'It's the slowest boyscout in the line' case.

In short, in a Bimodal IT environment, both modes need to move at the same pace in order to optimise productivity of the organisation. Value is created by products in the hand of the user, not by parts on a shelf or piles of almost ready products. This means that unless all relevant information is exposed by the Mode 1 systems, the Mode 2 systems will adjust their pace.

Decoupling not to the rescue this time

Mind that decoupling techniques like API's, ESB's, etc are not solving this problem. Interfaces are owned by the systems that implement them. No matter what method is used to define these interfaces. So thinking that there's an ESB, or an API manager or other decoupling technology will prevent the Mode 2 people to move as slow as the Mode 1 people is foolish.
Also, introducing a Canonical Data Model or some other data defined insulation layer will not help you either. In fact, that might, or rather will, introduce more complexity so will slow things down even more.
And let's be honest; Why would we need to insulate ourselves from working together. Understanding each other's contexts and limitations? Agile and DevOps is all about breaking down silos. Understanding that collaboration gets us further. And in the end we need to deliver products in the hands of the user. Having said that, there's no point in not changing archaic processes and apply some LEAN on them.

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 to my blog to all your Whatsapp friends and everybody in your contactlist.
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

API Management in Azure using Microsoft's solution - Why API's should be managed and by whom

This is a series of posts regarding the topic of API's and API Management on Microsoft Azure. Not all posts in this series are directly related to Microsoft Azure and their implementation of API Management, that is intentional. The series also explains about API's, about creating API's and about what it construes to in order to manage them, conceptually and in reality. The reason for this series is that over the past 12 months I've come across many articles on the web, have been in many discussions and advised various clients of mine on this topic. Sometimes discussing with fellow architects, other times with vendors, still other discussions where with developers and managers. But the overall situation has always been that none of the people at the other side of the table had a full grasp of what developing API's in an organisation means, what it entails to manage them or what should be worried about when deciding to go API. I hope you enjoy reading these articles, and when you feel like it, comment on the articles. I always take serious comments serious and will reply to my best effort.

I hope you've read my previous post on the topic of API Management, if not I strongly advise you to click here and read it.

Summary

Although managing API's has some resemblence with Looijen's model for IT management, the typical segregation between business and IT that stems from Looijen's model is disastrous for API management. API's need to be managed by a single team, the Product Team. Any other way of managing an API doesn't make sense. API's are products and should be treated that way.

API Management

API's are interfaces to (business) functionality that are accessed by, in theory, just about anybody. As can be read in my previous post, the idea of having API's and one of the main reasons why developing them is so hard, is the fact that you don't know up front who is going to call the API. The point in fact is that in a world of API's there is no room for the arrogance of the developer knowing exactly who is going to use the software and why. Instead, API's are inherently developed to support the case that the developer was wrong.

Because of this, when you expose an API, you'll need to make sure that you can support the API once it is deployed and used by somebody. Supporting means that you need to make sure the API is running consistently over time, the API must be usable and stay usable over time. Hence the API must be managed.
In order to do so, API's need to be managed on three different levels that to some extent relate to the support levels documented by Maarten Looijen, of which a description in Dutch can be found here. Basically he defines Functional, Application and System Management

The Looijen Model

(Skip this section in case you're not interested in the different kinds of support types.)

The model is not shocking as it states that there're three types of support that is required to support an IT system:

1. Functional Management. [Original text translated by Google:] Functional management is the management form that includes all administrative tasks that are required in the context of the use of information systems. As usage focuses on functionality, such as entering, handling, procurement, transportation and storage of data refers to information management.
2. Application Management. [Original text translated by Google:] Application management involves developing and maintaining applications. In the words of Parts and Looijen: "There may be many situations in which changes should be made in the original application software or database structures (...) Whenever such a situation occurs, application maintenance is performed but also.. when there is no direct reason is to perform application-maintenance, it is because of the continuity may still be required in order to maintain a complete management shape surrounding this executive task area application maintenance, including management and executive tasks. " Application management is like form, as it were about the task area applicate maintenance built around. It is to recognize application is essential that once developed information not evident also delivers the tools to easily support the change process (eg. Documentation). In addition, persons other than the original developers may be involved in the execution of modifications. Therefore it is important to maintain conditions which an application must meet so that they can be maintained 'easy'.
3. Systems Management. [Original text translated by Google:] Technical management includes the management form all tasks necessary to install, accept and operationalize and maintain information systems and technical infrastructures. Under technical management also includes optimizing processes and making changes in the technical infrastructure as a result of errors, extension or replacement. The technical management is focused on the technical platform, consisting of equipment associated with basic software, and implementation of information systems built on it.

Management of API's the Looijen way

Now that you understand what I mean by the Looijen model, it's time to inform you how API's should be managed.

API's are to be managed on the same levels as other software, that is the functional, the application and the system level.

System Level: On the system level, API's need to be managed such that they are made available. At the very minimum there should be an error stating the API cannot be accessed. At system level you manage the infrastructure on which the API is running. This might include some middleware as well. Since API's are to be called a lot, system management also covers scaling, i.e. elasticity, as well as all kinds of resilience aspects. Also security aspects like DDOS prevention, (web application) firewalls, etc. are part of the system management aspects of API management.

Application Level: On the application level, API's need to be managed such that they can be accessed, that the API documentation, (how to call the API?), is available, etc. Basically what it means is that there is an API to be called and that the technical aspects of the API itself are managed. For example the fact that an API accepts both JSON and XML parameters, that there is an API specific certificate defined such that the caller can verify the API call is served by a trusted system etc.

Functional Level: On the functional level, API's need to be managed such that they provide some value to somebody, preferably to both the consumer of the API as the team behind the API. API's are excellent for creating win-win situations, and these are business relevant situations. Basically what managing API's on a functional level means, is that you manage the relationship between the API and the consumer of the API. Think about a consumer having to pay for access to the API and setting different thresholds to control this.

When you look at the above different levels of API management, you may have noticed that on a system and an application level, managing the API is rather technical, but on a functional level it's really a business concern. Switching back to Looijen's model and you see that he makes a clear distinction between the two as well. System and application management are technical concerns, functional management is a business concern.

What if API's are not managed?

So what if you don't manage API's? The answer is actually rather simple. It becomes irrelevant, and in the end will seize to exist. For one thing, an API needs to be kept available. When it's not available, no consumer can access it. So on a system level it needs to be managed. This is no different from any other software application. Not managing an API on a system level results in the same chaos as not managing any other software, with the side note that API's are called by any(kind of) consumer, so the 'blast radius' cannot be predicted. From this, there's no reason not to manage the API on a system level as any software needs to be managed. There's one other point to be made here, and that is that an API needs to be kept available, meaning that it needs to scale, preferably horizontally and it needs to be resilient. Both are aspects that are not traditionally system management aspects as with API's this needs to be addressed on a software level.

On an application level things are getting a little convoluted with the system level management. In fact you might already have gotten the opinion that system level management is very much like application management and in fact you're correct. But system level management is more of a 'keep the shop open' issue, and application level management is more of a 'retain customers and grow your market' issue. When customer are not attended to, they'll go elsewhere. API's need to be managed on an application level as they are called because the consumer wants to. When the consumer needs to, eventually he'll leave for a more convenient API that provides sufficient added value to migrate to it. Hence the API needs to be amended to support other protocols, other data formats, more security etc. All aspects of application level management. See this as a matter of keeping the interface of the API consistent, but the implementation behind it evolving. So the API might be providing a consistent end-point to a consumer but evolves from a low-cost inefficient implementation to a costly but efficient implementation. This is API management on application level; replacing implementations behind an interface. If an API is not managed like this, it will become obsolete at some point. Obsolete API's are useless but cost a lot.

The system level and application level management concerns of an API are clearly required in case an API to some system or information is provided. When the API is not managed on both levels, the API will become irrelevant. But what about the functional level?

Functional management of an API is addressing an API on a business level. Read the post on API first design here to understand why API development is costly and if not anything else, the most difficult thing you can do in software development. Because it's so tricky, it's important that there's a business reason to actually do API development in the first place. And this is where functional management of an API comes to the stage. This is where it is managed that an API is monitored on a business level, for example keeping track of how many different consumers are using the API, how many of the consumers are 'returning customers' etc. Functional management of an API is all about managing the metrics about consumers of the API and act on them. Consumers that do a lot of calls may be willing to pay for each call to the API, consumers from specific industries will be more willing to sacrifice some performance in order to gain security etc.

When API's are not managed on a functional level, there is no point in developing an API. API development is so complex that there needs to be a business justification to do so. And it needs to be validated that the initial justification which is always based on assumptions, is correct. Not managing API's on a functional level will ensure that funding in the broadest sense of the word, will stop eventually.

Who manages API's?

API's are managed by both business and IT. Refer to Looijen again and you see that for software solutions, managing these solutions requires both IT and business. The same goes for API's. In a traditional organisation, one that has a clear separation between business on one side and IT on the other, API's are technically managed by IT and the developer of the API needs to provide an interface to the business to manage the API on a functional level.

Further complicating the scene, refer to organisations where IT is divided into a department that is more concerned about applications and the other department more about infrastructure. In this situation system level management is done by the infrastructure people and application level management is done by the application people.

Followers of the Looijen model are typically of the opinion that Application Support can be done by system managers. The reasoning often is that system managers are technically skilled people that understand applications as they understand the infrastructure on which the applications are running. And since they manage the technical aspects of the application and not the functional parts, they're more than suitable to manage the application as well as the underlying infrastructure. This view is incorrect (click here to read why) and when it comes to API's it's disastrous.

When you have an API based platform, and there really is no other way to have a platform, you need to consider the software implementing the API as well as the infrastructure on which it is running as a single system. It makes hardly any sense to see them as two separate pieces of the API puzzle. The reasoning here is that scaling, resilience and other aspects of the system level management of the API, i.e. managing the availability of the API, is an application or software concern that leverages infrastructure which in fact could be to a great extent be software as well. Therefore API's are preferably managed on both system and application level by the same team. Consider the API as a product and we're talking a Product Team here.

The importance of an API's availability and the complexity of developing an API leave no room for any other approach than a very tight cohesion between the API implementation and the full stack on which the API is running. Both the API and the underlying stack need to be developed in conjunction.

By the way, software developers shouldn't be concerned with system level management of the API and system managers shouldn't be concerned with application level management. Either both are in the same team, or the team consists of members that understand both levels of management, a rare breed indeed.

So what about functional managers of API's? These are business people, people that understand the business behind API's as well as the API they're managing. They're not technical people at all, they understand platforms, but from a business perspective. They can see IT as a product, and they discuss IT in terms of solutions instead of technologies. They're not Product Owners, they might be the most important stakeholders of the PO on some level.

API's have an implementation and they have consumers, but there're also people that make money of the API. It's the holy trinity of the API: Producer, Consumer and Beneficiary.

Because managing an API on functional level will have its repercussions on both the application level and system level of the API, turning the functional dials needs to be done in concert with the application and system level management efforts. Therefore, functional management should be done preferably by the same team as is taking care of the application and system management of the API. Resulting in a true Product Team.

Concluding

API's need to be managed because otherwise they will become irrelevant and obsolete. In this API's are not other than other software solutions. The complex nature of API's are an additional reason to manage them carefully.

API management can be discussed using the model by Looijen on IT management as all key aspects of his model apply and the clear distinction between business and IT exist with API's as well.

On the other hand, Looijen's idea of a clean segregation between business and IT and even within IT is not a logical segregation for API management. In fact, API's need to be managed by a single team on all levels of API management; The Product Team.

The complete series:

• API-first design
• API's and Architecture, match made in heaven 
• Why API's should be managed and by whom
• Resources and Templates [1/2] 
• Resources and Templates [2/2]

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 to my blog to all your Whatsapp friends and everybody in your contactlist.

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.

Iwan

Is there a market for the Cloud in the world of Corporates?

(Disclaimer: This is by no means a "definitive guide")

Abstract

I really think that most corporates are on an enterprise level not ready or even suitable to embrace the Cloud. It's the SMB that should embrace the Cloud as it would benefit significantly from Cloud offerings. Why? Because the cloud cannot be part of a policy, it should not be a strategy. Furthermore, corporates tend to only centralize infrastructure architecture and decentralize application architecture and the Cloud is driven by application architecture and business architecture and not (so much) by infrastructure architecture. In fact, it requires you to abandon control over your infrastructure and hand it over to your legal department.

Okay, I admit it, I've been an Amazon fan since I was ordering books and CD's for the whole department from Amazon.com, had them shipped to the office in the Netherlands at least on a weekly basis.
My hero in the corporate market? Jeff Bezos, the man behind Amazon.com. My biggest complaint on Amazon? That they haven't yet opened an amazon.nl store so I can purchase a Kindle Paperwhite for my wife and two sons and save some trees by getting them books in Dutch all digital. I sooooo badly want a Paperwhite myself, to replace my Kindle-with-keyboard, I sent my kids to English class so they could read books in English and I could give them my Kindle and buy the Paperwhite, with 3G of course.
Amazon has always been this very customer centric for-profit company, disrupting the market, any market by a single strategy: improve the ways consumers can spend their money at Amazon.

But this post is not about how awesome Amazon is, it is about whether or not the Cloud is for corporates.

First of all, depending on who you are, your response by now could be a whole heartedly and fully sincere "YES!". In which case you're probably a sales manager or similar person of one of the many companies that sell cloud for the enterprise services.

Second of all, well let me first cover the SMB market;
The SMB market is probably the single one market that benefits most of SaaS, Software as a Service, which is sort of a rebranding of the almost complete failure ASP offerings were. Being a company in the SMB market, you're too small to host many of the software you can get as a service yourself and by choosing the SaaS offering you can benefit from their economy of scale. It totally makes sense.
The interesting part of SaaS is that it is way less a matter of elasticity, which is commonly associated with the cloud (and rightfully so), but the emphasis is on self provisioning. As an SMB you would get services like Office365, Salesforce.com or the Google Apps offerings. All SaaS offerings. Things like IaaS and PaaS are not for you, unless your raison d'etre is a service based on online accessible services. Something called in the early days as a dotcom.
The Cloud is, for an SMB, interesting because the cost model is one based on use and not ownership. Your cloud provider meters your consumption and you pay what you consume. Your costs increase when your use increases and typically that means when you're growing as a business. The model is very fair.
So back to the second of all...

Second of all, the cloud doesn't really exist, it's a substitute word for different offerings, so actually the cloud might be there for corporates but what is the cloud anyway. Generally acceptable as a definition is the one provided by NIST. It also has a nice definition on IaaS, PaaS and SaaS.

SaaS

First SaaS as I already covered some SaaS when discussing SMB's just a few sentences earlier. SaaS is more about economies of scales to reduce costs related to the use of standard(izable) software offerings. For SMB's this is usually a small step as their processes are not that formalized, or at least they're typically rather flexible when it comes to their processes. Because in many ways, SaaS offerings are based on usage based on a best-practice.
Corporates are notorious when it comes to processes and adherence to them. From experience I know that the larger the corporate the more effort it takes to change a process and more importantly, the smaller the chance that their processes are according to best practices. So in this perspective, SaaS can be very cumbersome to implement because it would require a change in the processes of the corporate. Something about teaching old dogs new tricks springs to mind. Although it can be done, read "Who Says Elephants Can't Dance?" by Louis V. Gerstner, not dogs but elephants.

IaaS

So let's continue at the bottom, IaaS, Infrastructure as a Service. Basically what you get is a server, nothing on it, or maybe an OS. You deal with it. There's not a lot more to it and as a corporate you should already be familiar with this. It's what you've done for millennia, you bought new hardware with or without an OS installed and you took it from there. Whole IT departments are in place and ready to support this server. Typically the server is one of a really lot and over time your IT Operations staff has a number of very smart system admins.
The big benefit of IaaS is that you don't have to wait for the delivery of the hardware provided you drink sufficient glasses of water as the server can and should be provisioned during the period that you get up from behind your desk, walk over to the water cooler and get yourself a glass of water. From experience I know that it can take slightly longer when you're not yet a customer with the Cloud provider because you'll need to sign up as a customer. This is not a joke, with the current leading Cloud Service providers, this is the process and the timeframe during which the new server is provided. Will it be a physical or a virtual server? Well you don't know and you shouldn't care. It is the server that you want, with as many CPU cores and memory and bandwidth as you need. It's all provisioned from a seemingly unlimited pool of servers and CPU's and memory and bandwidth. Yup, there's some real magic going on, because the Cloud provider just keeps on providing servers to you, never asking you to stop asking for more.

Once you've got your sever, you're left at your own devices. The Cloud provider will not maintain that server at all. He will just ensure that the server is provided to you at all times and when it crashes that it will be available to you within the time you agreed in the SLA.
Did I mention that you need to take care of everything yourself and that the Cloud provider will not manage your server? It's not the service he provides when talking about IaaS, you are getting Infrastructure as a Service.

So why would you go for IaaS? Why would you go for infrastructure as a service? Well, just like you would go for any other technology; it solves your problem or it can sufficiently contribute to the solution to your problem. Most of the time you don't want to go for IaaS if there's a PaaS solution for you. Read on for the stuff about PaaS.

Onwards, with the things you can get as a service. PaaS, Platform as a Service, takes you up the software stack.

PaaS

So on top of the infrastructure, there is an Operating System and then some. Basically the 'Platform' in PaaS refers to the software layer on top of which an application runs. A lot of people I know are thinking 'Application Server' or 'Middleware' when talking about Platforms, but actually some applications run on the Operating System itself, so the OS might be the platform in PaaS.
Here's a rule of thumb that can help you: a Platform as meant in PaaS is any piece of software that is not a business application (take the term very broad) and is managed by the Cloud provider. Please take not of that last bit!
So in PaaS, the platform is managed by the Cloud provider, just like in IaaS the infrastructure is managed by the Cloud provider. Infrastructure is (virtualized) hardware, Platform is software. Is this arguably the correct definition? Yes, we can argue about it, but it fits the NIST definition, which is convenient.

Oh yeah, don't forget that the Platform in PaaS is a software layer on top of which an application runs. Typically it provides technical services to the business application. This means that typically a DBMS is not a Platform.
An Application Server like a JavaEE container, is a Platform.

Interestingly, the application server in the previous paragraph can be part of the PaaS service, so it is managed by the Cloud provider, or the OS on which it is running is the Platform and managed by the Cloud provider but the application server is not. The key here is what is and what is not managed and it always moves up the stack. So you can't have a PaaS contract where the Platform is an application server that is managed, but the OS is not managed by the Cloud provider. Anyone tells you this is possible, well question their expertise on Cloud, like really hard.

Typically you would want to go for PaaS, because that means that there's a lot managed by the Cloud provider and you only need to manage the contract with him including the SLA's you agreed upon. The Cloud provider will ensure that you've got your Platform and that it complies with the capacity you agreed upon, that it stays available and in case it becomes unavailable, that it will become available within the timeframe agreed upon in the relevant SLA.
You also want to move to PaaS if possible because it means that you'll be drawing on the fact that the Cloud provider has staff that can actually support the platform 24x7 so you won't need that expertise in your organization in the amounts of being able to support it 24x7.

Like with IaaS, a PaaS environment is provisioned quickly. A matter of minutes more likely than days or even weeks and months. And with a shear unlimited amount of resources at your disposal, so click away and get provisioned.

IaaS instead of PaaS

So why would you go for IaaS instead of PaaS, or maybe go for PaaS but only for the OS and not the application server, say? Well that is because you need something that's not standard.
Especially with PaaS, you will have to comply with standards. And these are not your standards at all, these are the Cloud provider's standards. And you're required to stick with them and not deviate from them because that's just not possible because you have nothing to say about the service except for the quality you're getting. The platform is managed by the Cloud provider and not you, remember.
So when you're in need, let's say, for a clustered WebSphere Application Server environment, you're likely out of luck getting that as a Platform, because it's too cumbersome to maintain such an environment. You're likely going to get the OS as a Platform and install you're own cluster of application servers on top of it.
The Cloud provider will provide you with separate, independent servers, or instances. All perfectly managed. This means that you'll need to ensure that the applications running on it support this. That they can deliver the availability requirements by themselves, not relying on the infrastructure.

What? I can't rely on the infrastructure for ensuring I meet my availability targets and RPO and RTO and stuff like that? That's correct. You cannot.
The separate, individual servers will be available and when not, they'll be available shortly. It's the managed part that will be made and kept available by the Cloud provider. The Cloud provider is not going to do whatever he can to keep the application available. Not at all.
So there's a strict divide between what the Cloud provider will take care of and what you'll have to take care of and there's little collaboration to be expected.
So if you need that business service to be available at all times so your customers can get access to critical information at all times, your application needs to be robust and resilient in a way that it does not rely in any way on the infrastructure it's running on, it cannot make any assumptions as to how the infrastructure works and whether or not there's anything specific running to keep the infrastructure resilient.
Well, that's a lie, there is something you can assume. Something you actually have to assume: The Infrastructure is a piece of crap and it will crash over and over and over and you have no control over it.

Why are IaaS and PaaS tricky for the corporates?

That's a good question, because they are actually very well suited to move to the cloud, the problem is in perception. The cloud is a technology, it's a means, it's a tool to solve a problem. It's a tool that has an impact on the organization of the corporate when employed. It also significantly changes the way a corporate will deal with it's IT resources. Control is achieved by means of contracts because the handson option is gone to the extent of the service provided to the corporate. So all of a sudden the legal department is the one that does Systems Operations, those men and women that have no clue what IT is, are required to draw up contracts and SLA's that are the equivalent of what the IT department used to do by means of actually doing stuff. This is for many corporates a huge paradigm shift, that requires a significant amount of maturity not only in its IT department but across the board. Something that is kind of not existent in traditional corporates.

Another issue is that from an (enterprise) architecture level, the Cloud is a strategy. It's something that should be used across the enterprise, but never put as dogma(*). It's not a generally applicable tool and it requires a very thorough understanding about what Cloud is, when it is to be applied and what the restrictions are. Interestingly it is quite different from for example stating that all systems should be on either Linux or Windows, or that all in-house developed applications are to be developed in C# using Visual Studio. Using the Cloud or however you want to call it, should never be considered an architecture principle. Because it isn't. This is very weird for large companies. I haven't seen many companies that understand this.

Something to take with you

One important aspect of IaaS and PaaS is that both are revolving around infrastructure, almost solely around infrastructure. But the decision to go for IaaS or PaaS or actually going cloud has nothing, well hardly nothing, to do with infrastructure, it is an application driven decision. There is absolutely no point in considering the cloud when your application is not ready. When it is not designed in a way that it can assume that the infrastructure is a piece of junk, when it is not designed in a way that it takes care of its own resilience instead of relying on the infrastructure you shouldn't consider the cloud.
The Cloud provider will not go beyond the service he provides, so he will not take care of your applications that are running in the cloud. He will simply just not do it. This is a good thing, because its not his area of expertise. In fact, application support is very labor intensive, it needs humans to do proper. And the Cloud provider is always looking for eliminating the human factor and do as much in an automated manner as possible. So the humans you would need for support are eliminated by the Cloud provider, in a non-felony way of course, in most cases.

Hope you enjoyed this post,

Iwan

*: Dogma is typically for those that have no clue what they're doing and just do because it's dogma. As most people are happy if decisions are made by others, because it would mean they don't have to think and they don't have to assume responsibility, dogma as easily embraced.

The Role of the Enterprise Architect

Hi,

Every once in a while I have to explain to people what the role of the Enterprise Architect is. And although this question isn't all that trivial at all, I still answer it with reasonable ease.

Disclaimer: I consider myself an Enterprise Architect, but with an IT perspective. This is important to note because it significantly limits my scope.

Another disclaimer, this post is from September 2011, since then, a lot has changed and although I've made some minor corrections in December 2014, you'll have to bear with me that the main gist of the post is 3 years old.

With that out of the way I can provide you with my answer to this question and explain it to you within the proper context.

Spoiler alert: The Enterprise Architect is responsible for formulating the vision for the mid and long term from a technology point of view, the IT Vision. A vision that is in-line with the business vision. He is responsible for defining a strategy that is to be followed in order to realize this vision, the IT Strategy. A strategy that is in-line with the business strategy. And consequently the Enterprise Architect is responsible for creating a roadmap that when followed implements the strategy, the IT Roadmap. The IT Roadmap consists of strategic business projects that implement key milestones and are fully in-line with the IT Strategy as well as strategic IT projects that facilitate in the implementation of the IT Strategy.

First of all I think that the Enterprise Architect's role differs from a Solution Architect's role in one very significant way; Where the Solution Architect is confronted with a problem and request to create a solution for it that complies with a given set of rules, laws, regulations, standards, guidelines and what not. The Enterprise Architect is confronted with the
current state of the world and an idea of how the world might turn out to be in the foreseeable future. And then is requested to define all problems to be expected to finally come up with solutions to all of them, such that they all comply with a set of rules, laws, regulations, standards, guidelines, etc. Some of which are unknown at the time the solution are defined.
Basically, the Solution Architect is given a problem and architects the solution, the Enterprise Architect has to come up with the problem first and then architect the solution.

With this out of the way, I can finally start answering the question: What is the role of the Enterprise Architect? His (or her for that matter) role is to create, govern and maintain the architecture of the enterprise from a technology perspective. Which more or less means that the Enterprise Architect is responsible for defining how the enterprise architecture as a whole is mapped onto technology. In the previous sentence I refer to the enterprise wide business architecture. And yes, I realize that this doesn't really has any meaning. Until, of course, I explain to you what I mean by enterprise wide business architecture. What I mean by this is the complete set of business decisions, visions, objectives, processes etc that have been formulated. It means the essence of the enterprise. The primary reason and motives of running the enterprise, its raison d'etre, if you would pardon my French.
The Enterprise Architect (from an IT point of view) is responsible for defining the IT perspective of this business architecture. He is responsible for defining which technology, principles, concepts, systems, applications etc are interrelated and how they are interrelated in order to enable the enterprise to meet its goals. And in addition he is responsible for maintaining this architecture, amending it as business goals evolve, and govern changes to it.

At this point I typically get the first blank stares from people. Rightfully so, because it is very abstract and Ivory Tower'ish. But there is a simpler answer which explains the role of the Enterprise Architect more clearly, in my opinion.

The Enterprise Architect is responsible for formulating the vision for the mid and long term from a technology point of view, the IT Vision. A vision that is in-line with the business vision. He is responsible for defining a strategy that is to be followed in order to realize this vision, the IT Strategy. A strategy that is in-line with the business strategy. And consequently the Enterprise Architect is responsible for creating a roadmap that when followed implements the strategy, the IT Roadmap. The IT Roadmap consists of strategic business projects that implement key milestones and are fully in-line with the IT Strategy as well as strategic IT projects that facilitate in the implementation of the IT Strategy.

Although the Enterprise Architect has to be constantly aware of the ever changing environment and adopt his architecture to remain in-line with the business architecture. This in part as a result of a changing business vision and consequently changing IT Vision. The Enterprise Architect will also have to reconsider his IT Strategy as well as his IT Roadmap based on a changing market. Typically in organizations this is a yearly recurring effort.
This caters for the creating and maintaining the IT Vision, IT Strategy and IT Roadmap in order to create and maintain the Enterprise Architecture. It does not cover the governance of the Enterprise Architecture. In order to implement governance, the Enterprise Architect is also responsible for defining and enforcing all policies and procedures that required for ensuring that project executed within the enterprise (both IT and business projects) are according to the set strategy.

For example, when the IT Vision is that the vast majority if not all (business) services are running in The Cloud [scroll down for a footnote on this 'vision'], and the IT Strategy is to implement in order a highly virtualized infrastructure which is then complemented with cloud administration services such that a private cloud is the result and finally all systems are moved to a public cloud as a means of out-sourcing the infrastructure.
The roadmap might be to initially select and implement virtualization technology, then migrate core systems to platforms that are supported in a virtualized environment, then select a cloud provider that supports the selected virtualization technology, then implement iteratively cloud administration tooling.
The Enterprise Architect is then responsible for ensuring that a set of policies, standards and guidelines are defined, implemented and enforced, that enforces applications to be cloud-ready. This may mean that certain paradigms are followed, for example that new infrastructure software and applications running on them are horizontally scalable in order to increase capacity such that performance requirements can be met.

It is utterly impossible to enforce compliance to IT Strategy for all systems, applications, projects etc. The Enterprise Architect, in collaboration with the business, will have to classify each project, system, application as being strategic, tactical or opportunistic.
Strategic projects (implementing core systems) will have to be completely compliant with the IT Strategy. These projects are implementing systems and applications that are planned to last for a long time within the enterprise and perform core functionality to the business. Typically they are planned to outlive the IT Vision or even the business vision.
Tactical projects can deviate from the IT Strategy but are required to be in-line with the IT Strategy. You could say they have to be in the spirit of the IT Strategy. These projects are typically implementing core business functions but for any reason cannot be implemented completely in-line with the IT Strategy. For example because the vendor does not yet support the selected virtualization technology for all components of the application.
Opportunistic projects are those projects that have a strong business driver to be implemented within a short time frame. Possibly because the particular bandwagon needs to be jumped on.

The interesting thing about an enterprise architecture is that treats those components that implement it on a physical level (hardware and software) as black boxes. At least to a certain level. The Enterprise Architect is concerned with the concepts of the various components but not so much with their implementation. By this I mean that the Enterprise Architect defines for example that all applications will have to run on a common application server infrastructure. This is the concept of farming, the infrastructure consists of a set of farms that host applications and applications components (application server farms, messaging farms, database farms). The idea behind this might be that infrastructural software is to be considered a commodity. How these farms are actually implemented (clusters of active nodes, clusters of active/passive nodes, etc) is not so much the concern of the Enterprise Architect but more for the infrastructure architects (middleware, database, etc), who in turn will be required to implement these farms compliant to the Enterprise Architecture. Even more interesting is that the Enterprise Architect is responsible for documenting the complete enterprise architecture as he own the enterprise architecture.

Although I realize that I haven't mentioned anything about the information architecture in this post, this is where I want to leave it to. Me for myself am not entirely sure whether the information architecture is part of the Enterprise IT Architect's responsibility. The thing with the Information Architecture is that it, in theory, is a business affair. The information architecture should be owned by the business. But practically I've seen it considered an IT affair in most pretty much every organization I've been. This is mainly due to the fact that the data architecture and information architecture are considered one and the same, which is in my opinion, because in most organizations it is considered to be impossible to create one enterprise wide information architecture. As a result, data architectures are not derived from a global or even local information architecture but from the physical needs of applications. But this is something worth its own post which I will work on some other time.

So this is what I consider the role of the Enterprise Architect as a role within an organization. But, there's more... Since the Enterprise Architect is one of the most senior roles within an IT department, if not the most senior role, I also think that as an employee within the enterprise the Enterprise Architect has also the responsibilities that come with this level seniority. In many cases the Enterprise Architect will have to act out of his seniority instead of his role. And this responsibility differs significantly from one enterprise to another.

Thanks for reading all the way to the end. It's become a long text, but I hope I've been able to explain my view on my role as an Enterprise Architect. Probably there's a lot you disagree with and I would love to hear about it.

Iwan

Footnote on the vision of having everything in "The Cloud"; Of course, it is not clear as to what the cloud actually is, even when you take the definition provided bij NIST. But the problem here is that everything in the Cloud is considered an IT Vision, which is of course not correct... but not uncommon, unless the  Cloud is considered placeholder terminology where the IT Vision is actually to no longer own physical infrastructure, not even from an outsourcing perspective.