In this post I will focus on roadmaps.  Whether you are building a roadmap for you overall architecture, for a portfolio of projects within a given domain of your architecture, or for reengineering business processes, roadmapping can be a challenge because of large amounts of legacy systems and ingrained behavior.  Many roadmapping exercises start with a long process of capturing the current state.  Often this leads to analysis paralysis and lots of time and money is spent while nobody is building the future state.

WWSD?

What would a startup do?  Well, a startup’s current state is that they have a blank sheet of paper and an opportunity to build the best possible solution with no legacy constraints.  Hmm, doesn’t that sound attractive?  I wrote a post back in 2007 called Getting to Future State where I recommended designing the future state first and then capture the current state later.  The reason is simple, if you start with the current state you immediately constrain the innovation process for future state.  Why not start with the perfect world and work back instead of starting with an imperfect world and adding to it?

Starting with current state can create undesirable results

Starting with future state can increase your chances for a desirable outcome

WWSD?  A good startup would map out what it wants to be when it grows up first and then work towards that goal while carefully managing its precious resources and capital.  A startup will also deliver early and often because it has to generate revenue, customer interest, and investor enthusiasm before it goes broke.  That is exactly what a corporation should do!  Deliver early and often making incremental improvements and proving its value to the executives (corporate equivalent of investors).

I have seen and been involved in too many promising projects where the next new technology, process, or organizational change was going to solve all of the world’s problems.  Each time these initiatives fell short of expectations and each time these new solutions were just another layer on top of the last solution.  Each layer added a new layer of complexity and legacy on top of the previous layer.  The reason for this is these teams started with what existed and figured out how to “wire in” the next technology, instead of figuring out how to move off or abstract parts of the legacy systems in order to take advantage of the newer technologies.

So the next time you have a roadmapping exercise, don’t start by analyzing what exists.  Start with a blank sheet of paper and ask “If we were a startup and were starting business today, what would the future state look like?”  Once you define what the perfect world looks like, then figure out how to get there.  You will likely find that you will have to make some sacrifices here and there but at least your innovative thinking was unconstrained when you envisioned the future state!

Comments

Before I give my opinion, let’s look at the definition of a private cloud as put forth by NIST (National Institute of Standards and Technology):

Private cloud. The cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on premise or off premise.

See entire cloud computing definition here

Based on this definition, one could argue that an on-premise private cloud is real and exists.  I won’t argue that.  What I will argue is this:

Does an on-premise private cloud make sense for any businesses other than vendors selling the hardware and software that allow private clouds to be built?

In my opinion, with a few exceptions, the answer is a resounding NO! (Yes, I just shouted).  Before I get into my reasoning let me explain why I chose to use the word on-premise before the word private cloud.  That was to differentiate between a private cloud contained within the walls of an enterprise, and a virtual private cloud, which is a private cloud provided by a third party.  Virtual private clouds (VPC) make sense to me because you are still outsourcing your infrastructure needs to a third party and greatly reducing your capex.  Of course, the term VPC has many different definitions too (that’s for another post some other day).

Now for my reasoning.  One of the biggest benefits to the business for cloud computing is the reduction of capital expenditures brought about by outsourcing hardware and data center costs to a third party provider.  Choosing to build your own cloud on-site is like building your own refrigerator.  Sure you can do it and you can have total control over it, but it is way more expensive, labor intensive, and will take you forever to get it done.  Wouldn’t it be simpler to just buy one with the latest and greatest technologies and energy efficiencies and just plug it in?  Now I am not saying that going to the public cloud is as easy as plugging in, but it is a heck of lot easier than building your own.

Here are some exceptions where I think an on-premise private cloud might make sense.

Government: In my mind, it makes sense for a government to create it’s own private cloud to provide low cost computing and security to its many agencies and divisions. With organizations as big as governments  with huge budgets and armies of resources, it may make sense to build a private on-premise cloud to service  a variety of locations and greatly reduce the costs by eliminating the redundancy of each agency having its own primary and secondary data centers.

Large multi-located conglomerates:  Extremely large organizations made up of numerous locations and numerous types of businesses can be served from an on-premise private cloud.  Just like with government organizations, a huge organization can actually reduce the number of data centers if they were to build a private cloud in a centralized data center and scale up and down to meet the needs of entire organization and its user base.

These types of private clouds can be argued to be a community cloud (here is the NIST definition):

Community cloud. The cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by the organizations or a third party and may exist on premise or off premise.

What about the rest of us?

If your organization does not fit into one of those two categories, I question why you think you need a private cloud.  My belief is that most who think they do are simply afraid of giving up control of their hardware, data, and network.  Now some people may argue that a hybrid model, public and private cloud combination, is the answer.  The concept of a hybrid cloud makes perfect sense where you keep your data in the private cloud and push as much processing as possible to the public cloud to get the benefits of cheap processing cycles.  However, is that really a private cloud or should we just be solving that with a service-oriented architecture, specifically a data services layer, where we leverage the cloud but access certain data elements on-premise?

Summary

Private clouds are a vendor’s dream.  As Dave Linthicum has been saying, many vendors are simply “cloud washing” their products and creating hype to make buyers think they need to build their own clouds.  Companies that buy this snake oil may consume their precious capital and human resources on long expensive projects just so they can declare that they have built their own cloud.  There is nothing wrong with not putting certain data or applications in the public cloud and simply leverage good architecture and virtualization internally to modernize the  data center.  Just don’t call it a private cloud.

Comments

From Cloud Computing

In this model, there are many requirements in the architecture that are specific to security, compliance, reliability, and scalability and are independent of the business functionality that will be deployed in the cloud. If you look at the image above, you will see many different endpoints where data moves from one cloud to the next, to SaaS solutions, and between virtual data centers. I call this the Cloud Infrastructure.

These requirements are also critical to the flow of data through out the cloud. Encryption, transformation, replication, backup/recovery, and many other tasks are key deliverables within any good cloud architecture. Then comes the services that transport business logic in and out of the cloud while inheriting the cloud infrastructure and data services that should be built for reuse. The following image shows a simple view of the separate performance layers of the cloud architecture and the order in which they should be tested.

From Cloud Computing

The first thing to do is test the performance of your cloud vendor(s). Looking at the hybrid cloud image above, I would test the flow of data from the different endpoints. At this point there is no need to worry about encryption, transformation, business logic, etc. When testing the Cloud Infrastructure you should be testing the performance of the platform that the cloud vendor is providing. Do not add variables that are specific to the business problems you are trying to solve. For a hybrid solution, test the private and public clouds separately. Your tests should run for several hours with varying size loads. You need to ensure that the cloud can sustain heavy loads, handle concurrency, and consistently deliver solid performance for all transactions. Testing at this level will also help identify configuration and optimization opportunities for each cloud vendor. Once both the public and private cloud infrastructure is tested, then test the intercloud connectivity between them. Make sure this connection is not a bottleneck.

Once you are satisfied with the performance of your hybrid cloud, it is time to analyze the impact of encryption, transformation, data replication, and the various ways that data is being manipulated to address security, compliance, reliability, and scalability requirements. It is critical to understand the impact of these requirements on the overall performance of the system. If you skip this step, finding performance issues later can be like finding a needle in a haystack. People can waste a lot of time searching for performance issues in the business logic when the problem may be in the data layer. Manipulating data can be resource intensive and a potential bottle neck of the overall architecture. Spend some time testing this layer before overlaying it with business logic.

So now you feel good about the Cloud Infrastructure and you have iterated through the design of all of the data manipulation requirements. You now have a solid foundation for your business services. You can focus all of your energy on the the performance of your services. Test each service individually first. Then test the flow of data through the various combinations of service calls that the system is expected to perform. Put these services through rigorous testing and measure their performance for load, sustainability, concurrency, etc.

After the business logic has met the performance requirements, it is time to test the systems as a whole. Up to this point you have tested the system at different layers within the architecture and at different components within the layers. Now it is time to test the system holistically and in the eyes of the end user. It would be very expensive to find performance issues from the lower levels of the architecture at this point. That is why I recommend the layered approach to performance testing. What I also like about this approach is that you can start testing very early in the life cycle. For example, you can test the performance of the Cloud Infrastructure way before the development team delivers the business logic. This approach is iterative and agile and aims at removing performance risks earlier in the lifecycle thus reducing the risk of project delays.

Comments

• Consumer privacy
• PCI compliance
• Security
• Lack of control
• Data location requirements

Where have I heard of these issues before?  Oh yeah, when we were moving from the mainframe to client server.  How did we solve those issues?  Oh yeah, we designed for these issues and mitigated the risks.  What does it mean to the business if I can figure this out?

• Huge reduction in infrastructure costs
• More flexible and affordable disaster recovery and business continuity
• Possibly even better security
• Easier growth/expansion into new markets/countries
• Pay-as-you-go scalability

As I have mentioned in the past, I am working for a startup building our core product/services from the ground up.  We have no plans on having our own data center and are leveraging the cloud as a low cost to entry into the market place.  Also, the cloud gives us world class infrastructure and scalability that we would never be able to afford or raise capital for.  So we have all of the incentive in the world to figure out how to use the cloud for transactions.  We have no legacy to bog us down, no data to port, no culture transformations to lead…..just a blank sheet a paper, an open mind, and an entrepreneur spirit!

So how can we build a secure enterprise in the cloud?  We started by adopting the E2AF framework and defined the business architecture first which is completely agnostic of the technology.  Some of the many items that were identified from the business architecture were:

• Security and compliance are critical to the success of the business model
• Data may be required to physically be stored within a country or customer boundary
• Need to be able to scale quickly (customer acquisition cycles should be same day, not months)
• Speed to market and low cost is a key differentiator

The bottom two bullets scream out for the cloud.  The top two scream out for on-premise.  Maybe we could compromise.  How about a hybrid model?  Public cloud for speed, scale, cost and private cloud for security, compliance, and co-location.  What would that look like?

From Cloud Computing

You can see from this picture that all sensitive data is kept on a private cloud. In this model, we are not putting consumer and financial data in a shared environment as is the case in the public clouds. Here we are dedicating specific servers that we can lock in a cage and harden just like many people do on their own raised floor. In fact, if I already had an existing data center, I would have the physical data layer deployed in it and not on the private cloud. The private cloud is not as cost effective as the public cloud, but is a heck of a lot cheaper than buying and maintaining a full blown data center. So how does the public cloud access the data on the private cloud? Can you say SOA, specifically data services. That’s right. SOA is alive and kicking in this architecture! The services in the public cloud talk to the data services layer and have no idea of how and where the data is physically located. To these services, a customer, an order, an invoice are all defined in business terms and the data services layer will figure out how to retrieve the physical data from the appropriate location over a secure protocol. This also addresses the data location requirement which is not addressed with typical on premise solutions. Imagine an architecture that leverages both public and private clouds across the globe that looks like this.

From Cloud Computing

In this example I focused on the US and Europe (apologies to my colleagues in other countries/continents). Since the data location requirements dictate that data may need to be stored at a client’s headquarters or within the boundaries of that client’s country, separating the data into the private cloud or a remote data center allows me to still leverage the low cost capabilities of the public cloud to run the rest of my services.

IaaS vs. PaaS

One of the keys to this architecture is the use of Infrastructure as a Service (IaaS) and not allowing Platform as a Service (PaaS) solutions for delivering our services in the public cloud (see “Clearing up the Cloud Picture” definitions).  The reason is simple.  Our transactions must be up 24×7×365.  That means that we will use two providers in case one fails.  To do that, we must not use a proprietary platform that would require a rewrite to move to another platform.  We must build our services to be agnostic to the vendor platform (did I hear you say SOA again?).  One of the big risks of cloud computing is an organization’s dependency on a third party for up-time.  Vendors also go out of business or get bought by other vendors, see my response to the Coghead fiasco.  It is key that the architecture does not get married to the vendor’s platform and is free to move when and if the need arises.

Security & Compliance

I already addressed some of these issues by leveraging the private cloud and dedicating servers for the physical storage of sensitive data.  But that by itself is not enough.  You still need to protect against unauthorized access from your vendors’ employees and you still need to do the basics for securing the servers.  Here is a short list of things to plan for:

• Secure the OS
• Secure the database
• Secure the network
• Secure the endpoints
• Have a logging storage and retrieval strategy
• Restrict access (Ex: cages, fingerprint ID, etc.)

From a compliance standpoint, adopt some formal standard and build those standards into the security layer of the architecture.  This allows you to manage security in a centralized place by those that know security instead of depending on every developer to do the right thing when they are building services.  I had a security company do an assessment of all regulatory constraints across all countries and found that the combination of PCI compliance and ISO 27001/27000  covers the majority of regulatory requirements across the globe.  That is the advantage of adopting an internationally accepted standard from the ISO.

Control

Most of the control issues are geared around knowing where sensitive data lives so audits can be performed.  In a public cloud environment you have no idea where your data is which makes auditing for things like SOX or PCI next to impossible.  Also, since  you are on a shared environment, another company’s actions could lead to the government seizing assets under the Patriot Act (thanks W!).  If all of your sensitive data is on your private cloud on dedicated servers, the Patriot Act is a non-issue (assuming you have redundancy in the public cloud).  I also recommend using cloud management software to effectively manage virtual servers across the various vendors and across the public and private cloud.  Even on the dedicated servers in the private cloud, you can still leverage virtualization to scale up and down and quickly launch new images.

Conclusion

Many pundits will tell you that the cloud is not secure, not reliable, and not ready for prime time.  If we are talking about the cloud as a stand alone entity, then the pundits are correct.  But if we take the various cloud offerings and build an architecture that addresses redundancy, security, compliance, location specific data requirements, and is vendor neutral, then the cloud can create a major competitive advantage that can enable a company to leap frog its competition.

Comments