Enterprise Architecture

Three Enterprise Architecture Principles for Building Clouds

Bricks

After having gone through TOGAF training and certification, I've now caught the Enterprise Architecture bug, as you can probably tell by this article. It is a really neat way to add structure to the IT development process and to better understand what it really means to solve business problems with IT.

One of the first things TOGAF recommends architects do when establishing an Enterprise Architecture practice within a company is to formulate Architecture Principles that guide the development of solutions. During the last few workshops and during some discussions with other architects, three principles in particular struck me as being key to successfully developing a Cloud solution:

The Difference Between a Standard and a Preferred Vendor

Standardization

Recently, I attended a customer workshop where the customer declared that they standardized on x86, VMware and Linux.

That got me and my colleague thinking about what standardization really means and whether that actually makes sense.

The workshop was actually about defining a PaaS platform for the customer, and early in the process they just said: Fine, but it's gonna be x86, VMware and Linux, because that's our standard. WTF?

Engineered Systems and Enterprise Architecture (or: How to Sell Dog Food Online)

A dog. And the TOGAF ADM cycle.

One of the first things that customers and sales teams realize when dealing with Engineered Systems is: They fundamentally change the IT architecture of a business.

Change is good, it means progress. But change is sometimes seen as a bad thing: Change comes with fear.

The truth is that Engineered Systems really empower IT architects to add value to their business, application and data architectures, without worrying about the technology architecture.

To understand this, we need to dig a bit deeper into Enterprise Architecture, specifically the TOGAF flavor of it.