Cloud Native Enterprises - Rapid elasticity

Which don't have a lot to do with Cloud Native Apps but everything with truly embracing the paradigm shifts the Cloud has brought IT within the realm of businesses.

Read the Introduction first.

After reading the introduction to these posts you know what a cloud infrastructure is and what cloud native applications are, what about cloud native enterprises. Well these are enterprises that adhere to these same 5 characteristics. These enterprises, or organisations in general, cannot be modelled according to traditional enterprise models because of their specific market, competition, growth-stage, etc. These enterprises need to be, for all accounts, be cloud native in order to grow, succeed and be sustainable. Interestingly, but not surprisingly they require The Cloud and Cloud Native Applications.
In coming posts I will address every essential characteristic of The Cloud as defined by NIST from a perspective of the Enterprise. Unlike most cases, I will post these within the next 7 days and I certainly do hope before coming weekend.

• On-demand self-service. When online services and core systems really seamlessly integrate.
• Broad network access. When customers, partners and users are distinct groups treated equal.
• Resource pooling. When synergy across value chains makes the difference.
• Measured services. When business resources are limited.

Rapid elasticity. When business is extremely unpredictable.

Very few organisations can say that year round they experience the same amount of business. Almost every organisation experiences something like a 'season'. There are always highs and lows in an organisation's load. This can be 'Black Friday/Cyber Monday' for retailers, tax-season for the IRS or its equivalent in your country, or for example hotels during the summer holidays.
But not only in sales, there are highs and lows, often very predictable, but in production companies there are peaks in order fulfilment.

In order to deal with these fluctuations in 'business load', organisations need to be elastic. The more elastic an organisation is, the better it will be able to handle the fluctuations. Mind, this is not the same as being agile. Being agile is being able to change direction as needed, in a timely manner. Being elastic is being able to change scale as needed. Also in a timely manner. Arguably, being elastic is more difficult to accomplish than being agile.

Elasticity is a matter of scaling up, and down. The more elastic an organisation can be, the more efficient it can do its business. Efficiency here is a matter of spending just enough. Another difference between elasticity and agility. The former being about efficient in using resources, the latter is about being effective in resource utilisation.

From the Cloud we know that elastic means scaling up, or down of the IT infrastructure in order to manage fluctuating load. Thus not having to worry about under-utilisation of IT infrastructure, thus paying for infrastructure that is not being used. And at the same time, not having to worry when load increases and the stability of the environment isn't compromised due to over-utilisation of that same infrastructure.

In the Cloud Native Enterprise, we project these traits onto the organisation itself. Onto the business.

Traditionally, scaling organisations are hard to accomplish. Extremely hard in fact. For one there is always the challenge of resource availability. Where resources are of course human resources. The most common way of addressing this is through contractors. The hiring and firing processes around contractors are far more flexible than for permanent employees. Thus bring some elasticity to the organisation. But getting the 'bodies in' is only part of the challenge. Getting the 'right bodies in' is another aspect. Adding personnel with the right skills is possibly even harder. First you need to find them, next you need to validate that you found them. The hiring process is cumbersome and the further you need to stretch the organisational elastic band, the harder it becomes. The amount of effort needed is not increasing linear, but almost exponential.
Organisations need to be able to scale up quickly. Which often also means that the HR department needs to be elastic as well. Again, the same challenge apply.
In an economy with an up-beat, there are more companies that are looking for the same scalability and resources become even more of a challenge to find.
I haven't mentioned the strain on the organisation itself due to growing too large. More management layers need to be introduced in order to be able to grow and manage this. And this is where scaling down becomes a problem. Adding more management layers in the hierarchy to handle the size of the workforce, is relatively easy compared to removing these layers again.

The more seasonal a market is, the more of a challenge elasticity becomes for an organisation. Tax-offices will be overloaded with calls to the help-desk as the deadline for submitting your tax-forms nears.

At one point I was involved in a court-case as one of the expert witnesses where my client succumbed at its own success. The client was in a business where 98% (!!!) of its revenue was generated in 5 consecutive days of the year. It couldn't handle the increased business as it couldn't predict what that load would be. Especially since in the months prior to their 'peak' they took over their largest competitor.

Organisations can't scale their workforce to the point where we can talk of elasticity. Scaling up and down is a matter of weeks. Where elasticity is the ability to scale up and down in a matter of days, hours or even minutes and less.
This is where the Cloud comes in. It is not so much the elasticity of Cloud infrastructure that plays a role, but the ability of an organisation to utilise the Cloud such that it can scale its business efficiently. Cloud infrastructure is an important part, where it comes to handle IT load. But the true business elasticity comes from handling at a business level the fluctuating load.
Extreme automation of business processes allows an organisation to reduce its dependence on specific business knowledge of its employees. Everybody can press a button or enter data when the 'system' does the heavy lifting in applying business rules and execute repetitive tasks. Understand that by following this paradigm, the reliance of the organisation on less-educated employees is reduced to a bare minimum, and it can focus its efforts towards attracting higher educated employees. Employees that require less managerial guidance which allows for a more flattened hierarchy. Flat hierarchies are more elastic.
Automated processes can in addition, benefit from the technological elasticity of the Cloud. Thus having a double edged sword.

Elastic organisations are not trivial. Far from it in fact. Main reason being that traditionally, organisations scale with their business by either increasing its workforce through short term contracts, i.e. contractors, which can be hired and fired as needed. Or by attracting permanent employees and assume a positive attitude towards the future. Or laying off personnel in advance when the future is perceived less positive. It is how organisations are used to manage the seasons.

The Cloud Native Enterprise on the other hand is far from traditional. At its core it will embrace technology resources not to replace human resources, but to complement them. It invests in senior, higher educated experts, to reduce the reliance on management. In effect, pay more to less, in order to reduce the need to scale the workforce.

Concluding

And so the Cloud Native Enterprise is the enterprise where IT is part of the business when it comes to delivering business products. Allowing a business to grow and shrink as needed, just ahead of time and with the flexibility of a rubber band.

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.

Cloud Native Enterprises - Broad network access

Which don't have a lot to do with Cloud Native Apps but everything with truely embracing the paradigm shifts the Cloud has brought IT within the realm of businesses.

Read the Introduction first.

After reading the introduction to these posts you know what a cloud infrastructure is and what cloud native applications are, what about cloud native enterprises. Well these are enterprises that adhere to these same 5 characteristics. These enterprises, or organisations in general, cannot be modelled according to traditional enterprise models because of their specific market, competition, growth-stage, etc. These enterprises need to be, for all accounts, be cloud native in order to grow, succeed and be sustainable. Interestingly, but not surprisingly they require The Cloud and Cloud Native Applications.
In coming posts I will address every essential characteristic of The Cloud as defined by NIST from a perspective of the Enterprise. Unlike most cases, I will post these within the next 7 days and I certainly do hope before coming weekend.

• On-demand self-service. When online services and core systems really seamlessly integrate.
• Resource pooling. When synergy across value chains makes the difference.
• Rapid elasticity. When business is extremely unpredictable.
• Measured services. When business resources are limited.

Broad network access. When your business hours are truly 24x7.

This is an interesting aspect of the Cloud Native Enterprise. Because many organisations are already 24x7 businesses. Especially in the online world, being always on is a requirement to stay in business. 

Network here is not referring to the the computer network on a technical level as we know it. According to NIST, one of the characteristics of the cloud is broad network access, which from the definition, this means that the cloud is always accessible through the internet. The computer communications network.
Within the context of the Cloud Native Enterprise I am referring to the communications network of the business. On the one side, this encompasses all parties a business has dealings with. Think customers, users. partner, employees etc. I will get back to this later on in this post. But it also encompasses all means through which this communication takes place. Think devices and associated channels.

So, when we look at the business that is truly cloud native, when we talk about broad network access, we mean that the business is accessible by its complete business network, via a variety of devices and channels.

The Cloud Native Enterprise exposes its services, all of its services, in the same way to customers as it will to users and partners, as well as employees. Every member of every group enjoys the same level of service and the same constraints. Distinctions are made using the concept of role-based access to services. Still all services are always accessible to all members of the network through the same channels. In addition, it will provide the same level of service through all channels on all devices. Ideally. Of course contextual limitations are to be taken into account.

Traditional Focus - Cost vs Value

Consider the more traditional enterprise, where customers are assigned a specific account manager. The account manager maintains the relationship with the customer. She has specific KPI's that need to be met and she is more or less free in determining how to achieve this. Users of the customer are not aware of the account manager, instead they interface through a help-desk with the enterprise which will consists of self-service functionality for the more mundane support, automated systems like chatbots and more complex interaction through a help-desk agent.
Partners of the enterprise on the other hand, will work with peers within the enterprise. Informal contacts are more prevalent and accepted. Where customers and users will need to follow the formal processes in order for the enterprise to be more efficient, partners will follow the informal communication lines in order to be more effective. We see in traditional enterprises that with customers and users, processes are cost driven. Partner oriented processes are value driven.

Cloud Native Focus - Revenue

In the Cloud Native Enterprise, all interactions are focusing on revenue. Key aspect here is the homogeneous approach towards interaction with stakeholders. Customers, employees, users, partners are all considered stakeholder of the enterprise. Access to the enterprise is homogeneous across the full network, and processes are optimised for revenue. Sometimes resulting in focus on efficiency, other times on effectiveness.

What you will see is that business scalability, both temporal and geographical, is addressed explicitly. Every stakeholder in the enterprise's network can access the enterprise 24x7 and from any location.

For every organisation this is a challenge to manage. But for the Cloud Native Enterprise the mere premise of the Cloud as an IT facilitator, it becomes a matter of survival.

Consistent User Experience

The Cloud is great for realising products and services that scale with your business. Not talking about elasticity here, but about the ability to have a single approach towards addressing your stakeholders' needs and demands.

Leveraging the characteristics of the Cloud, including its technical aspects of broad network access, means that it is possible to provide all users of all services and products with a consistent user experience. This entails the same experience provided to customers, partners, employees etc. This consistent user experience across all services will allow for a seamless transition for a user from one role to another.

Concluding

As with its technical counterpart, (broad) network access is a key characteristic for the Cloud Native Enterprise, as it will provide a homogeneous approach towards accessibility of products and services across the full breadth of the business network

(Special thanks to my colleague Mandeep for pointing out some much needed clarifications in the original post)

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.

Cloud Native Enterprises - On-demand self-service

Which don't have a lot to do with Cloud Native Apps but everything with truely embracing the paradigm shifts the Cloud has brought IT within the realm of businesses.

Read the Introduction first.

After reading the introduction to these posts you know what a cloud infrastructure is and what cloud native applications are, what about cloud native enterprises. Well these are enterprises that adhere to these same 5 characteristics. These enterprises, or organisations in general, cannot be modelled according to traditional enterprise models because of their specific market, competition, growth-stage, etc. These enterprises need to be, for all accounts, be cloud native in order to grow, succeed and be sustainable. Interestingly, but not surprisingly they require The Cloud and Cloud Native Applications.
In coming posts I will address every essential characteristic of The Cloud as defined by NIST from a perspective of the Enterprise. Unlike most cases, I will post these within the next 7 days and I certainly do hope before coming weekend.

• Broad network access. When customers, partners and users are distinct groups treated equal.
• Resource pooling. When synergy across value chains makes the difference.
• Rapid elasticity. When business is extremely unpredictable.
• Measured services. When business resources are limited.

On-demand self-service. When online services and core systems really seamlessly integrate.

This is the post where I'll address the aspect of the On-demand Self-service. An aspect which for many organisations is rather challenging. Just like the aspect of Measured services, this aspect is addressing internal governance structures. Although the governance implications will touch on the financial governance of an enterprise, the challenge is more of an organisational nature and in fact  the financial parts are not always relevant.

In any case. When we talk about on-demand self-service within the context of Cloud Native Enterprises we talk about an enterprise where tools and technologies needed to explore or exploit business models can be obtained when needed, by the person that needs it. Often we talk about IT resources, software and or hardware. But think in terms of services, which are often IT services.

In a traditional environment, IT services are obtained by the IT department. This is where the IT experts are and this is where the required frameworks for 'proper IT' are defined and used. Business departments will request, based on functional specifications, certain IT solutions, experts within the IT department will make sure that the best solution for the lowest price will be procured, installed and configured. Hassle free operation for the business people as a result.

Traditionally the reason for an IT department is centralisation of these resources in order to make as efficient use of these experts as possible. Actually, what I most often see is that within IT departments there are separate teams for specific expertise, so called Competence Centres or Centres of Excellence. Efficiency has been a key objective for many years within organisations, often because IT resources (computers as well as personnel) were relative expensive compared to other resources.

As efficiency has been a key objective in these traditional environments, the scheme above played out nicely. Scarce personnel is being utilised optimally in terms of keeping them busy and in the meantime, their experience and knowledge ensured the best value for money possible. Time was not a factor until recently. Of course, it always took too long to provide the solutions to the business, but offset against costs, this has always been a small price to pay. Relatively speaking, and yes, pun intended.
But things have changed and the old timelines are no longer acceptable. Timing becomes more and more an issue. Business ideas can no longer wait to find their way into the hands of users. Not only because lean, agile and nimble Start-Ups will chip away the market shares of enterprises, but because enterprises between themselves are leveraging technology to get the competitive edge.
We see that the introduction of The Cloud in the IT departments of enterprises has resulted in extremely short timelines when it comes to delivering solutions to the business by their IT departments. Enterprises with an IT department that can't leverage the characteristics of The Cloud as defined by NIST will perish. You can't move fast enough? You're shark food. It's a dog-eat-dog-world nowadays.

The CIO v.s. the CDO

We see that CIO's are being complemented by CDO's, Chief Digital Officers, in those enterprises where the CIO has not been able to transform the IT department from a traditional silo'd business enabler into a heterogeneous multi-disciplinary flat business partner. CDO's are introduced to drive the digital transformation, a transformation that has been going on since the advent of computers in enterprises. But where it focused on efficiency and controlling cost in the past, now the transformation is focusing on effectiveness and creating value. Often the CIO hasn't been informed about this new direction as often the CIO is not in the boardroom. Understand that in many of the organisations I've been, the CIO reports to the Chief Financial Officer, instead of the CEO, COO or the Chief Marketing Officer. IT is associated with cost in these enterprises and not with revenue.

Product/Platform Paradigm

But in the Cloud Native Enterprise, it isn't the IT department that delivers IT solutions, not even when they can do this with the speed of The Cloud. In these enterprises, the business services it self.
When IT solutions are needed, the business will obtain them by themselves. Here the IT department is no longer delivering the solutions, but the platform onto which the solutions will run and integrate with the core IT systems. Systems like Identity and Access Management, Monitoring and Metering, Resilience and Disaster Recovery. Integration of solutions in the platform is what IT is about. Products and business solutions is what the business is about.
The IT departments in these enterprises are basically nothing more than in-house system integrators. But extremely sophisticated at that since integrations are subjected to profound automation.

It is with Cloud Native Enterprises where we see the true value of the Product/Platform paradigm. IT delivers the platform, the platform is its business product. Business delivers business products. This is where the concept shines as those that understand how to valuate the product from a business perspective are accountable for the product that creates the value to the business.

Concluding

And so the Cloud Native Enterprise is the enterprise where IT is part of the business when it comes to delivering business products. Allowing business solution to be created using IT on-demand, through self-service. This also means that the traditional IT department has become a business department as well, run as a revenue catalyst and not as a cost centre.

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.

Cloud Native Enterprises - Measured service

Which don't have a lot to do with Cloud Native Apps but everything with truely embracing the paradigm shifts the Cloud has brought IT within the realm of businesses.

Read the Introduction first.

After reading the introduction to these posts you know what a cloud infrastructure is and what cloud native applications are, what about cloud native enterprises. Well these are enterprises that adhere to these same 5 characteristics. These enterprises, or organisations in general, cannot be modelled according to traditional enterprise models because of their specific market, competition, growth-stage, etc. These enterprises need to be, for all accounts, be cloud native in order to grow, succeed and be sustainable. Interestingly, but not surprisingly they require The Cloud and Cloud Native Applications.
In coming posts I will address every essential characteristic of The Cloud as defined by NIST from a perspective of the Enterprise. Unlike most cases, I will post these within the next 7 days and I certainly do hope before coming weekend.

• On-demand self-service. When online services and core systems really seamlessly integrate.
• Broad network access. When customers, partners and users are distinct groups treated equal.
• Resource pooling. When synergy across value chains makes the difference.
• Rapid elasticity. When business is extremely unpredictable.

Measured service, when business resources are limited.

This is the post where I'll address the aspect of the Measured service. It is an interesting aspect of the cloud native enterprise because it addresses the financial governance model of the enterprise.
Let me first start with what I witness in most organisations regarding the financial governance model. Great and small, old and new. And even in start-ups. The model is in about all cases one in which there is an annual budget allocated for pretty much everything that costs money. Often times, the budget is based on past experiences. It's a copy of last years budget corrected, or extrapolated, based on last year's developments, revenue, target met or not, etc. What I often times see, and I'm actually pretty sure I have seen this in all but one or two cases, is that once a year there is a prediction as to what the business will look like in the coming year. This is not the strategic plan, but next year's plan. There's a project portfolio, or more recently a product portfolio, that covers the coming year. Predictions are made about next year's resource needs etc.
The most common thing here is that the more resources an organisation has at its disposal, the more anal the enterprise is about these plans.

Being ambitious as a business

What I hardly ever see is a prediction of what the enterprise's ambition is with respect to its market position. Its business ambition. Do not mistake this for a strategic ambition, or a mission statement. What I am talking about is an 'objectives portfolio', an overview of the enterprise's objectives. Each of it's value chains, lines of business, P&L areas, however the enterprise's business is divided should have objectives, and ideally a roadmap littered with objectives. This is the objective-portfolio.

Why this is so important is that an enterprise should be working to meet these objectives in any way it can. And the reason why this is so important, is that these objectives are in fact the key drivers for business sustainability. From a strategy perspective, the business objectives should be completely in line to support the strategy. By working towards these objectives, the strategy is implemented, which in turn will increase sustainability.
An important key take-away is that objectives can be met in any number of ways. There is hardly ever only one way to do so. But in general, out of all the different ways to achieve an objective, there are only one or two that are the best. The best within the context of the enterprise at a specific moment. Which means that what is the best way now, might not be the best way in the next quarter. There could be a missed opportunity, new regulation, or a shortage of resources. So re-evaluating the the proper course of action continuously, should be a given.

For enterprises resources in terms of money are often not considered a bottleneck, instead I see often that the availability of the right people to do the job to be a problem and in even more cases the precious resource we call time is a problem of its own magnitude.
For smaller companies I see that often money is the issue and people and time not so much. Reason being that smaller companies tend to focus more on a limited amount of business solutions. Where enterprises are straying all over the place, small companies are equipped with laser sharp focus.

"Now where's the Measured service coming into play?", you ask.

Measuring achievements not performance

Working with a roadmap based on objectives, with a portfolio of objectives, allows for embracing the concept of validated learning, and metered funding.
Like I stated earlier, objectives are met by choosing one of many implementations, where the choice is based on the context of the moment the choice is made. For example the timing to introduce a new consumer product just ahead of the holidays. Or the introduction of a key competitor's product that will pave to way to broad market acceptance of something controversial. Or the abundance of developers that can code in specific programming language. By consciously choosing the seemingly best implementation to meet the objective, you know what to look for in order to re-evaluate that decision. Staying on track with the calendar to meet the holiday boom, monitoring market acceptance of that product, keeping an eye on Craigslist for job postings for those coders, etc.
Obviously this requires monitoring of the results of your efforts, but that is exactly what it means to apply the concept of 'validated learning'. You determine based on what your efforts are contributing to the bottom-line (whatever that is to you) or not or is even counter productive, this is your hypothesis. You undertake whatever action you've got up your sleeve and once you're done, you check your hypothesis and determine what your next move should do. It's actually pretty close to just being agile.

Turning variable into fixed

Now the trick is, and this is where it becomes extremely complicated for enterprises, to allocated resources in such a way that you can continuously work on meeting the objectives, but change the way you do so, throughout the year. From a financial planning perspective, this is rather different from most enterprises I've seen over the years. Like I stated earlier, budgets are allocated annually, based on plans. The the bigger the budget request, the more assurances need to be given to get the budgets allocated. Business Cases are written, plans are drafted, dreams are... well often the most realistic and accurate of these three.
The way I often see it addressed is by introducing pre-funded teams. Which basically means that one of the larger portions in the budget is fixed, namely human resources. In fact, this only addresses the problem when an enterprises HR strategy is relying heavily on out-sourcing, contractors or a combination of these two. When most of the work is done by own staff, HR costs are already fixed, and working with pre-funded teams is merely an HR-planning issue. I would prefer this situation, but it is often just not feasible. With pre-funded teams, a large part of the budget is fixed, which is an accountant's dream, or so I've been told on various occasions. How to fix all other variable costs? That's a challenge, but this is where a cloud environment helps, as it will not fix IT costs, but it will allow these to be limited to the bare minimum as needed, so costs are not fixed, but risk is contained and limited. Another dream coming true.
Your measured service at play here is now that for one a large chunk in the budget is no longer variable, so planning is straight forward, no measuring is really needed as the teams are based on objectives to be met and not work to be done. I understand this is the first time I phrase it this way but it is crucial to understand the different. I leave you to think about it for a second.

Concluding

Measuring is needed for the remaining chunks in the budget. Although still variable, this chunk, the IT resources costs are contained and limited and investments are only needed when the IT is required. And more importantly, revenue is generated shortly after investments are done, or else further investments are stopped. So we measure the revenue, off-setting it to the limited costs.

I hope you understand the paradigm shift in the financial governance from a mainly cost driven concept where revenue is mainly a matter of wishful thinking, educated guessing at best, to mainly realised revenue based.

Re-iterating. Measured services relate to the fact that the in the cloud native enterprise, the enterprise is governed such that costs are considered investments. But only concerning those costs that can't be fixed. In other words, variable costs are considered investments. Investments are related to business objectives to be met and not work to be done. This eliminates in a large part the risk that the focus is on work already done instead of objectives still to be met when it comes to new investments.




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.

Cloud Native Enterprises - Introduction

Which don't have a lot to do with Cloud Native Apps but everything with truely embracing the paradigm shifts the Cloud has brought IT within the realm of businesses.

A couple of weeks ago I was asked to do a presentation to a number of mainly (project) managers on the topic of "The Cloud". I think one of the reasons I was asked had to do with the fact that I usually tend to be (a bit) iconoclastic and another reason might be that I have been a huge proponent of The Cloud. Look at previous posts of Arc-E-Tect and you should be able to find a number of posts on the topic. In any case, I obliged.

While preparing the slides, digging into my archive of presentations as I remembered a presentation I did on the topic a couple of years ago to a group of mainly lawyers and auditors I decided that it was the perfect time to not talk about The Cloud as an IT phenomenon but as a business phenomenon. As you might have gathered when reading my posts on this blog, I do tend to see IT from a business perspective. Pure simple logic dictates that we apply IT in organisations to strengthen our businesses. The decision was made, I was going to talk about Cloud Native Enterprises.

The Cloud According to NIST

What are Cloud Native Enterprises? First of all you need to know what The Cloud is, and I always use the NIST definition of Cloud. NIST made it easy to define The Cloud by naming 5 essential characteristics of cloud:

• On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.
• Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations). 
• Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth.
• Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.
• Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

(source: The NIST Definition of Cloud Computing)

There's not really an order in these characteristics, but they are essential. You have to keep in mind that these are related to IT systems, typically infrastructure hosting services.
I'm not going to re-iterate these characteristics and explain what The Cloud is, instead I'll go over these essential characteristics to explain what a Cloud Native Enterprise is.

Cloud Native Applications

But before I do this, let me explain what a cloud native application is, because it is important to understand this. First of all; Every cloud native application can run in a traditional data center. Second of all; From a NIST characteristics perspective there is no difference between public and private and hybrid clouds. As long as all 5 essential characteristics are met, we can talk about a cloud environment.

Back to the cloud native application. This is an application that thrives on the cloud. It is one that uses the 5 characteristics to the fullest and doesn't compromise. Let me go over them one by one.

• On-demand self-service. A cloud native application is accessible by a user, which could be another application, but often it is a person. But it is not only accessible by a user, but everything pertaining that user can be done by the user, whenever the user pleases. So the user can sign-up herself, configure her environments herself and do whatever she needs to do, all by herself. Irrespective of the role of the user. So an administrator of the application can do whatever needs to be done, as can a business user. This is hugely different from traditional applications, where you would need to request an account at some service-desk in order to gain access.
• Broad network access. Cloud native applications are network accessible and not only that, they're accessible through standard mechanisms and through common devices. Typically we see that these applications are accessible via the internet, or at least through internet protocols. Often we use http or https to access the applications. Originally through a browser, but with the advent of mobile devices we see that the generic web-browser is replaced by a specialised browser, the client application, that accesses the application's logic via web- and internet-protocols and presents a user experience fully embracing the client device's capabilities.
• Resource pooling. This for applications means that the applications are multi-user applications and the users are not aware nor impacted by each other, unless of course, business logic demands interaction.
• Rapid elasticity. Probably the most unique selling point of the cloud is elasticity. The amount of resources needed to perform a specific task consistently independent of the load on the systems is expanding or retracting as needed. Elastic. No wonder Amazon calls their virtual server environment Elastic Cloud Compute (EC2). For cloud native applications the same goes. The application scales up and down as needed by the load on it. Typically this is done using the underlying infrastructure's elasticity, but mind that the cloud 'nativeness' of the application is that we're talking about functional elasticity. The responsiveness of the application is consistent across many workloads. This can mean that the application's functionality scales down when load increases (e.g. loading only the first 3 review comments for an item in a web-shop instead of 10) and scales up when the load decreases.
• Measured service. Here we run into the situation where the usage of the application is metered. At any time it is known what the application's utilisation is. Which user is using what functionality at what time with which guarantees. The idea here is, obviously, that the user will be billed based on her usage (of resources) of the application in contrast to some flat fee or a compute-power based fee. An example is that a free-tier account can access a certain function only once every two seconds, where a pro-tier account can access the function 5 times a second. The key here is metering and billing.

Every time I use the word 'user' above, I want to reiterate, it can be a person, but also another system. Especially in the current API economy, the user mentioned will very likely be another application.

Applications that are cloud native adhere to these 5 characteristics, and they do this from a business functional perspective. There are all kinds of technical implications like a transition from ACID transactions we typically see in traditional applications, towards BASE transactions we see in cloud native applications. Same goes for in depth security in the cloud and more of a focus on perimeter security in traditional data center hosted applications.

Cloud Native Enterprises

Now that you know what a cloud infrastructure is and what cloud native applications are, what about cloud native enterprises. Well these are enterprises that adhere to these same 5 characteristics. These enterprises, or organisations in general, cannot be modelled according to traditional enterprise models because of their specific market, competition, growth-stage, etc. These enterprises need to be, for all accounts, be cloud native in order to grow, succeed and be sustainable. Interestingly, but not surprisingly they require The Cloud and Cloud Native Applications.

In coming posts I will address every essential characteristic of The Cloud as defined by NIST from a perspective of the Enterprise. Unlike most cases, I will post these within the next 7 days and I certainly do hope before coming weekend.

• On-demand self-service. When online services and core systems really seamlessly integrate.
• Broad network access. When customers, partners and users are distinct groups treated equal.
• Resource pooling. When synergy across value chains makes the difference.
• Rapid elasticity. When business is extremely unpredictable.
• Measured service. When business resources are limited.

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.

Perish or Survive, or being Efficient vs being Effective

Summarising

In IT we are not dealing with commodities, although it may seem to be that way, it isn't. Software development is a matter of engineering and not producing. Hence efficiency is not the focus you want to have as a business, instead you want to be more effective. Effectiveness is what is required to be adaptable to a market where changing one solution for another is becoming increasingly trivial. Open standards and the democratisation of IT resources because of the cloud ensure users that the risk of vendor lock-in is negligible. This requires an organisation to be able to adapt to the wishes and needs of its users, not being able to churn out loads and loads of software. Therefore in order not to perish in today's world, effectiveness is needed not efficiency. To thrive in such a world you'll need to be efficient at being effective.

Over the past couple of weeks I had some discussions with a colleague of mine. He's an architect as well and we're in similar situations where we are asked to coach teams and organisations to transition from a traditional setup into an agile setup.

Last week or I was asked by this colleague if I could co-review a report one of his clients wrote that was all about a transition from a legacy waterfall organised project into an agile project. What struck me, and fortunately my colleague concurred, is that the main motivation for this transition was to become a more efficient organisation. Which in fact is an ill-chosen motive.

Let's back-up a bit and consider two similar words that are fundamentally different in meaning: Efficient vs Effective. Traditionally, in process engineering we're striving to become more efficient. The whole idea is that by becoming more efficient, you can produce more and hence benefit from economies of scale and the likes. It's a process improvement adagio that's been around since long. It is also a motive for improvement that leads to silo's, specialised silo's. And here you already see the first sign of why efficiency is wrong when it comes to agile methods. In an agile world we want to get rid of silo's not create them.

So where's the effectiveness coming into play? Well, that's actually rather evident. In order to be agile, you need to be able to turn on a dime at a moment's notice. Which means that whatever you do, you need to be very effective when you do it.

The point here is, that Efficiency focuses on minimising cost by spending as little as possible on the creation of a product on a per product basis. By doing so, the cost of the product reduces and the profit margin per product increases. Typically this is achieved by leveraging specific capacity for specialised tasks. Effectiveness on the other hand focuses on maximising revenue, by spending as much time on value creation by doing what is needed. By doing so, the costs of the product increases but the relevance of the product for the consumer and therefore its value increases more and this has a positive effect on profit. Typically communication lines between dependent parties in a process are shortened by introducing multi-disciplinary teams.

It makes sense to focus on efficiency when you need to produce large quantities of some product, and you know that there's no to hardly any need for diversification. For example when you produce nuts and matching bolts, it makes sense to produce them at the lowest cost possible. Efficiency is for growing your market share with a commodity product. Instead, when you need to grow your business by growing your market instead of your market share. Or where your product is anything but a commodity, efficiency is killing. You'll perish, eventually.

Considering you're in IT, that's most likely why you're reading my blog, your product is anything but a commodity, even when it's a commodity. And growth, especially sustainable growth, is accomplished by growing your market, not your market share. So drop the urge to be more efficient and become more effective.

Point is that you need to be able to adapt to your market. Your user, not even your customer, will initially not have a clue what she needs. Hey, that's why you've adopted agile principles. But once she is up to speed on what her demands are, she'll be more and more demanding. Hence you need to be able to adapt, continuously. And no, it's not adaptation in the IT department either, but your business needs to be able to adapt. And there's the catch, or rather your answer. Because by becoming more efficient in your production line, i.e. your IT department, your business will become less agile. This is because you've optimised the production process and software development is an engineering process. And before you ask, software development is a case of engineering and not producing. That, by the way, is the reason why off-shoring and out-sourcing is so cumbersome.

So you want to be able to adapt your product, you being the Product Owner, as the one being accountable for the company's profit (or loss). Or at least partially. So you want to be able to adapt your product, so it complies with the wishes and definitely the needs of your users. This requires a team that's effective, not a team that's efficient. Meaning that you want a team that can do pretty much everything needed to adapt the product autonomously. Not a several teams that can do specific jobs very efficiently.

This is why you need to focus on effectiveness instead of efficiency when you want to make the move to agile. And I'm convinced that you need to make the move to agile ways in order to survive and not to perish in this world that is changing faster every day. Organisations that are lean, nimble and agile are the ones that will survive in the long run, where the length of long is becoming shorter every day.

So where does this leave the architect in all of this? At the centre of agility. The architect is the one that is perfectly positioned to define what kind of competencies, qualities and personalities are needed to make a team into an effective team. The architect is also the person that is in a position to ensure that a product is adaptable. A product's adaptability and therefore a business' agility is determined by its architecture and the product team's perfectly equipped to make it so. More importantly though, the architect is in a rather unique position to not only ensure that product teams are effective and business becomes agile, but also be very efficient at this. Only when you architecture is in order and your team is effective will you be ready to improve on your efficiency, allowing you to not only survive but actually thrive.

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

API Management in Azure using Microsoft's solution - Resources and Templates [2/2]

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.

This post is the last post in of a series on API Management using Microsoft's solution.

API Management is not the same as an API Manager. In short, API Management is what you need to do with your API's, and an API Manager is something with which you can do this. There are a lot of different solutions that allow you to implement API Management, one of these is Microsoft's solution on Azure. The tricky part is that when you start reading their documentation on API Management you'll read little about how to actually implement API Management in your organization using their solution. It's all very conceptual. This shouldn't be a problem since the concept behind API Management are more important than the actual implementation… until you want to actually implement it.

Read the previous posts on the topic to learn more about the concept, continue reading this post to learn more about how to use Microsoft's solution in Azure, their cloud platform.

Resources and Templates

Finally, resources and templates, the bricks and mortar of the cloud. In the cloud you're typically dealing with resources. An infinite amount of resources, or at least that's how it feels. Everything in the cloud is, or should be a resource. Some are very basic like computing power, storage and networking. Others are more comprehensive like database, firewalls and message queues. And then there are a quite a few that are truly complex and very useful on a high level, for example directory services.

The cloud, being what it is, is like a normal infrastructure on which you host something that generates value for your business. Hence everything you need to run business applications in a traditional hosting environment, you also need in a cloud environment. Obviously there are significant differences between traditional hosting platforms and the cloud, but when you don't take too close a look, you're likely not to see these differences.

So in the cloud you also need to define systems, attach storage, put a firewall in front, put connectivity in place etc. You can do this by hand every time you need an application's infrastructure. Typically through a portal by clicking your way around and assemble the infrastructure. But more sophisticated and a way better practice, is to define the infrastructure in a text file, typically JSON for most cloud platforms, and use the cloud vendor's tooling to create the infrastructure based on this file. As such, the file becomes a template for a specific infrastructure setup you need. By providing a parameter-file you can externalize specifics of the infrastructure. For example the URL's to locate a web-service can be defined in this parameter-file to distinguish between an infrastructure intended for testing and the same infrastructure intended for production runs.

The particular template is called a resource template, it defines which resources are needed and how are they specified in order to run a business application.

One of these resources that you can use is an API manager, just like you can specify databases and virtual machines as resources. And here's your challenge.

The challenge is in that an API Manager consists of three parts;

1. Developer portal, used by developers to find your API's and their documentation.
2. Publisher portal, used by API developers and the likes to manage the API's.
3. Gateway, used by applications developed by those mentioned above in 1 to access API's managed by those as mentioned above in 2.

Each of these have their own context and is used by a different group of 'users'. The real interesting part of the API Manager is the API Gateway as it is the component that exposes the API's you've been developing. This is your product. It is the resource that is part of your software. And the thing is; it can be shared or limited in scope to just the product you're developing.

Ideally you would have one gateway per product, because the gateway and particularly the API's it exposes, are part of your product and as your product evolves, the API's that come with it will evolve as well. And of course you would want a consistent life cycle across all components that relate to your product. Since the API gateway is just like any other resource in Azure, the above is perfectly doable. In fact, it is possible to include the API gateway as part of your product's resource template and when you provision the relevant infrastructure and deploy your product on it, the API gateway is provisioned as well.
Pretty awesome, when you're willing to forget that the costs of an API gateway are pretty steep. We're talking about close to €2,5k / month. There's not really a price based on usage. Microsoft is really weird in that when it comes to pricing in the cloud. That whole pay-per-use is not really everywhere in their pricing schemes. I like Amazon better in that regard.

So an API gateway per product is not really an option in most cases I would argue. Instead, I would advise to have a gateway per product suite. In case you have teams that handle multiple products, scope the gateway to such teams, or otherwise scope the gateways to department. Use it as a rule of thumb though and not as the law.

The point here is that you want to be able to have your API's evolve with your products and that you want teams to be as independent of each other as possible. But in addition you want your API's to be operated independent of each other. And this is important. In Azure, API's don't scale, it's the gateway that scales. And you want to be able to be smart about that. Especially when it comes to policies and usage tracking or rather generating value from API's being used. When a team is responsible for the success of its products and therefore the value that is being generated, it becomes obvious that that team would want to be able in control of what is affecting their success.

The alternative would be to work with an SRE approach, where you have a team that's responsible for your platform, including your cloud platform(s). This team would then realize the API gateway for the other teams as a service. The catch here is that this platform team decides where your API's are 'hosted', or rather whether or not you share the API gateway between teams or not. Unless your platform team is really committed and more importantly has a thorough understanding of what API's really are and I mean really understand this, I would advice against this approach. I would oppose it for the sole reason that your API's are the window into the soul of your organization. When the API is not performing well, your organization is not performing well. And especially when you're going API first, and thus build a platform, you're screwed without proper API management.

In case you do decide to go the platform team route, make sure that your processes are completely automated. Including the deployment of new API's as well as new versions of existing API's. My preposition here is that you'll be working agile as can be, deploy to production as soon as you're confident that your software is up to it. Meaning that new software needs most likely new (versions of) API's. Don't make the platform team a bottleneck, so make sure that you're working with them to deploy the changes API's consistently, repeatable and consistently. Better to abide by their rules then put your own in place. Drop the whole platform team approach when they're not providing a 100% automated deployment process for your API's.

Then there's the portals. The developer portal is a tricky one because it provides access to your API's from a developer perspective. You should be really nervous when you're nervous about potential unwanted developers nosing into your API registry. Because it means your security is way, way, way below par. Remember, API's are different from regular services in that they are build such that they make no assumptions as to who accesses them. And unless you've build them that way, you'll be in for some really serious security challenges. That said, there's no reason why not to have different portals for developers within your organisation and developers from outside your organisation. And have API's exposed only to internal teams and publicly exposed API's. Just make sure that this is an exposure aspect and not, I repeat, not an API implementation aspect.

So develop API's as if they're possible accessed by just anybody and their mother. Expose API's to a subset of this group.

Then there's the operational aspect of your API captured in the publisher portal. Here you should take an approach that only the team responsible for an API should have access to the API from a management perspective in an operational environment. In other words, access to an API's policies is for the team that 'owns' the API only. You'll need to take care of that. period.

Mind that Microsoft is rapidly changing their API Management service on Azure. Most likely. as I type this, they're making life easier for you on using the service in your organization. The concepts as I've described still hold though. And as Microsoft will hopefully come to realize that also for API Management a pay-per-use model is the way to go, you'll be able to treat API Management as part of your product instead of as part of your platform.

This concludes my series on API Management using Microsoft's solution. I hope you did enjoy it.

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.

Arc-E-Tect

Roadmaps are why you should ditch your architects

Summary

Architects that are not with you along the way are of no use. You should not pay too much attention to them, they're not worth the frustration they cause as nothing good will come from it.
But if you find yourself in the company of an architect that is trying to be with you all the way, you should cherish that architect and consider yourself extremely lucky. Not only because your life will be better, but more importantly because this is a very rare breed.

Classification of Architecture Irritation

In case you're interested in finally getting that excuse to get rid of your architects, you're most likely frustrated with them, their architecture and probably you are not able to see any added value of the architect in your organisation. Therefore, I think you'll most likely fit into one of these groups:

• Your architect is too technical and strict, and that the architecture is too restrictive and technical.
• Your architect is just the right person for the job, and a great job he's doing with that just right architecture.
• Your architect is too high-level and vague to be helpful, and that the architecture is too high-level and vague to be useful

And in case you are an architect, you will fit in one of these three categories and your surroundings classify you as either too strict, awesome or just not helpful at all.

Now think about it really carefully... if you're the just right architect or you're dealing with that architect. Since how long do you feel that way? Has it been forever? Well, then this post isn't for you, but continue reading anyway. In case your answer is something like 'just recently' or 'since not so long', then this post is for you because there's a reason why it's been not since forever and it's bound to change in the near future. Well, it'll be very likely you'll going to move to one of the other groups.

The roadmaps are what make architects roadkill

When your architect already is one of those that you can't really consider useful, and is creating architectures that are not really helping you. Or when you're one of those architects. Well, you're in for a treat, because this is a cause of possibly the main frustration within your IT department. Or even within your whole organisation.

Now why is this?

This is because these architects only add time and costs to your projects and nothing else. They too often behave like auditors, telling you what's wrong and not how to fix it. But other than auditors, the architects refer to something they created themselves in the past, using the RTFM reply.
Auditors are a pain in the buns because they point you at how you're not playing by your own rules. Based on what your own definitions of good and bad are and what is and what's not acceptable, they'll verify to what extent you play by those rules. Architects, too often, will work on a reference architecture, architecture principles or even guidelines and that's it. You use their output to work on your own products. And you'll notice that as soon as you start using their stuff, it's either too restrictive (we develop software in either Java or .Net), too outdated (we develop our software based on JavaEE 5) or too vague (we develop our software based on the multi-tier architecture). Whatever it is, it's not helping and as soon as you ask your architect to do a scan of your products, it will be noticed that you're not using Java or .Net but NodeJS instead, that it's based on Java 8 or that it's an architecture based on SOA principles utilising a serverless infrastructure using Amazon Lamda.
So by either abiding the rules written or checking to what extent your compliant, you're loosing time and wasting money.

In many cases this is because people think architecture is a noun, while it is in fact a verb. Let me repeat that;

Architecture is a verb, and definitely not a noun!

So when you document an architecture, you're documenting a living thing. Something that is changing constantly.  So understand that when you come across a document with an architecture, look at the date of the document, because it's a snapshot of what the architecture looked like at that date. Or rather, it's likely to be the case.

But it doesn't end there, architecture isn't just some thing that changes constantly. It's an opinion of somebody who is mandated to be opinionated. What this means is that the architecture is also showing where you want to go as an organisation with your IT landscape. It's the as-is, the to-be and the route to get there. It's like a sat-nav system, it determines based on GPS coordinates where you are on the map, you enter your destination and it will calculate the route to follow to get at your destination based on your location. This is architecture. Well, part of it. The part that's relevant for this post.

That reference to driving and navigation is something I've done before. Read about it here. It's how I explain to my kids what my job is. I see where my client is, I negotiate with him where he would like to be and then come up with a plan how to get there. Including a clear definition of the impact on his situation along the way. Goods and the bads of the trip.
When you look at how many architects work, it's no surprise that they're so frustrating. The analogy with the SatNav is very clear in this;
There're those that will just hand you a (road)map and you just figure it out. See where you are, find where you need to be, plan your trip and go. And oh, btw, the date on the map is likely not very comforting. Or you'll get a turn-by-turn overview of how to get from A to B, based on the outset of when you started to plan your trip. It's based on some possibly old view of the world and any changes to the roads, terrain or otherwise are hopefully taken into consideration. But any traffic jams or other obstructions along the way are not in scope.
And then there's our trusty connected SatNav system. And the analogy holds. Because this thing is connected to the world. It not only keeps track of where you are during the trip itself, but it will keep an eye out to where you will be shortly. That won't be your final destination, but in case there's some roadwork up ahead, it will guide you past it. You'll be informed about relevant information along the way about gas stations and gas prices, hotels, restaurants etc.
The interesting part here is that those that have ever driven with a map, remember the fights between the driver and the person reading the map. Or those near death experiences when you were driving and reading the map yourself. And in case you printed that yahoo page with the turn-by-turn route to wherever you thought you were going to end up, you'll remember that all of a sudden there's a lot of places with the same name, roads are always under construction and the turn-by-turns are always irrelevant after the 5th turn or so.
These are the architects that think architecture is a noun.

The SatNav is constantly with you, and the better the system the more it anticipates on the road ahead, keeping you informed about your surroundings, distance to destination as well as the arrival time. It will keep in mind that weather conditions might be cause to divert your trip or maybe start the AC to make sure that the climate in the car matches the weather outside. This is when architecture is a verb.

Architects that are not with you along the way are of no use. You should not pay too much attention to them, they're not worth the frustration they cause as nothing good will come from it.
But if you find yourself in the company of an architect that is trying to be with you all the way, you should cherish that architect and consider yourself extremely lucky. Not only because your life will be better, but more importantly because this is a very rare breed.

Conclusion

I did already post about project managers and their demise here. Well, it's not a lot better when it comes to architects. Actually it's worse, because these architects, the ditch-able ones, are useless even in waterfall projects, but more so in agile projects, I give you that.
But where you can still find some use for most of the architects in waterfall projects, because as you know, these projects consider documentation as a key deliverable and are run under the premise that after creating the documentation for the next 12 to 24 months they don't need to change. In Agile projects this is different and this is why many scrum teams have said their goodby's to architects and even organisations have stated that architects are no longer need. And yes, this is the best thing that could have happened to our profession as IT architects. It's a matter of weeding out the turn-by-turn style and map style architects.

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