Three Enterprise Architecture Principles for Building Clouds

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:

Cloud Architecture Principle #1: Standardization

Principle

When establishing a cloud solution, there should be only one standard, and it’s the point of service where you standardize the kind of cloud service you provide to your cloud customers. No other standards are necessary or useful after that.

Rationale

As explained here, a standard is really only an interface you define for the purpose of providing a service to your customers. Nothing more, nothing less. Anything below that point is your responsibility and should not concern your customers, anything above the point of standardization is your customer’s business and not yours.

It’s the clear separation of Cloud provider and Cloud consumer through a standardized Cloud interface that enables the necessary independence you need in order to maximize efficiency of your Cloud service.

Implications

The standardized interface should be minimal: Just enough service to be useful and no more, to ensure flexibility and independence. The standard should also be implementation agnostic, so you’re free to choose how to implement your Cloud service without being dependent on what your Cloud consumers do with it.

This is the magic behind Amazon-style Cloud optimization: They only give you a simple API, then optimize the heck out of it below their chosen API level.

Cloud Architecture Principle #2: Optimization

Principle

Optimize as much as you can below the point of standardization.

Rationale

This is key to your cloud’s success: Cloud computing, from the point of view of the infrastructure supplier is nothing more than a ruthlessly optimized way of supplying a well defined (see point of standardization above) service. All bets are off here, as long as you focus on providing the most efficient implementation of your Cloud service.

Commercial break: This is the reason Engineered Systems exist: They’re ruthlessly optimized cloud building blocks for well defined Database, J2EE and other services.

Implications

There’s no need for or utility in adhering to limitations here. As long as you satisfy you Cloud service requirements, you’re free to choose whatever technology, architecture or other means are useful in providing your service. This is good news for those who always wanted to break out of their “This is how it has always been done” mentality and like to start something new.

Cloud Architecture Principle #3: Separation

Principle

The implementation details of your Cloud service should always be hidden from your customers. They should never know how exactly you provide your J2EE, database or other service, and certainly never depend on the particular way you do it.

Rationale

This is basic layer separation hygiene: As soon as the consumers of your service start depending on some detail of your implementation, you lose the ability to change that detail because now you have to satisfy backward compatibility to a feature you haven’t committed to in the first place. Therefore it’s best to make it clear upfront what the minimum set of supported features are, and to hide any extra features that may or may not be present, so you’re free from entanglement between service and implementation.

Implications

This also means you need some sort of filter that ensures any specifics of your Cloud service implementation are hidden from your consumers. If your J2EE service is implemented using, say, WebLogic, your consumers should never know, and in particular should never be able to tell. This is one of the beauties of Solaris Containers: You know what you get, but you never know how and where that Container has been implemented, so you can’t really take advantage of any machine specifics.

Conclusion

So here they are: Standardization, Optimization and Separation. Three principles that you should keep in mind when designing a Cloud solution, and adhering to which can save you a lot of headaches.