By Michael A. Tiemann, Senior Faculty and Program Director FEAC Institute
Now, more than ever, the need for understanding and planning the support for business and mission services, computer automation and data and information management through the implementation of Enterprise Architecture is quite important. Enterprise Architectures should be leveraged heavily and relied upon to inform decision makers about the viability and advisability of organizational attempts to extend processes and data into the cloud computing realm.
This article explores how EA facilitates, integrates and congeals aspects of process enablement, services orienting implementations, identifying and validating security provisioning, and ensuring that organizations utilizing collaboration have performance and transparency considerations built in to ensure that the Clouds don’t become thunderheads, spinning out unexpected tornadoes wreaking havoc throughout business mission processes and raining out expected improvements to services or capabilities. As the virtualization of IT services extends to the cloudy world of service agreements, if the attorneys become the ones who have to sort out the issues, the storm is already upon us. We hear that cloud computing is the wave of the future providing everything from desktop services to back office support, remotely when and where needed, with all the bandwidth and speed needed. This may be the case but it won’t be without planning and that means architecting the solutions and services before contracting for them.
Many leaders advocate following the phrase made famous by Nike, “just do it”, with respect to Cloud Computing or listen to the Silver Bullet hucksters who say just buy our stuff. Lucky for them, they will have already moved on when the hale storms break out of those hastily decided and implemented solutions, from clouds that should have been architected before they were implemented, but weren’t. Issues from scalability to affordability and from leveragability to stability need to be considered in a well defined and architected cloud approach. Practitioners, IT managers and architects who have figured out ways to link their cloud strategies into or driven them out of their architectures with conscious attempts to avert risks and failures are succeeding in taking advantage of the virtualization approach. Those who don’t, well, lets just say that an umbrella won’t help because they’ll be needing disaster relief, and their customers will be the ones left out in the cold.
So how will architecting help with ensuring a successful virtualization in the clouds. Let’s break it down by the layers of Enterprise Architecture. First, we’ll consider the Business layer and the related performance metrics. When using the EA discipline to model the business missions and functions to the extent that they are documented and understood from both an “as they are now” to a “way we want them in the future” state, it is much easier to see opportunities where the virtualizations can be easily implemented with full understanding of the risks and rewards. Activity models and use cases, for example, enable the questions to be raised in what if scenarios that answer whether there is too much risk in releasing control to service providers as opposed to keeping certain activities’ support in house. Most importantly the costs versus the risks in the context of the performance expectations can be weighed.
Next let’s consider the information and data layers of the EA. When the clouds have the information required for on-going key or critical mission processes, transactions or negotiations, for example, and for some reason communications to it is interrupted, that is not the time to wish there was local back up or copies on certain other alternatively available resources. Also, having put processing of certain activities or transactions in the cloud as well as the resultant data can limit its use for certain analyses and management feedback purposes unless carefully planned for. Security of these data in the clouds are also aspects that must be understood and identified, architected in, before something unexpected or adverse happens (like the cyber theft of un-encrypted credit card numbers, as an example.) Clouds can be secured, but the security must be driven by the understanding of the business requirements, because all aspects of securing data additionally add complexities and overhead. Even if the Business mission processes and the data and information are clearly and carefully articulated in models and the requirements for the virtualization world understood, there are aspects of the systems and services that also require architecting.
At the conceptual and logical levels understanding the efficiencies and effectiveness of putting certain services in the clouds is also very important. While it may come to pass, that at some point, there will be a commercially available capability, fully integratable with local or corporate services, portals and service shells, for almost anything a business or mission enterprise in a particular domain (like banking or health), that’s just not the case today. Much of the support for the capabilities is built and ported to the clouds or custom built for the enterprise in its own cloud environment. There are issues of legacy applications integration and expensive interfaces, data access ownership and sharing, service components sharing and optimizations that all affect the viability and capabilities provided. This is of course all dependent on the communications, the networks viability and the availability of bandwidth. These are technical considerations, but they stem from aligned and derived business needs and considerations and they must be architected to ensure delivery and lower risks. This means that the actual business considerations affect the service agreements and the design criterions applied. This can be very detailed and tricky stuff and risking the business on putting the services in the clouds is a weighty proposition so why wouldn’t one apply the EA discipline, if it can be even a modicum of insurance, to lower risks and increase the rate of success?
Lastly, we have the physical implementations of the technologies that support the cloud approach. This typically means ensuring a level of operational capacity and local computing speed and agility, connoting faster processors and more capable and upgraded devices. Whether we are talking small laptops or hand held computing devices, with wireless connectivity, there will be set ups and updating services to support and align with the cloud strategies. The alignment of the devices and how they integrate into the business mission practices and procedures as well as the provisioning policies and service support all come to bear and affect the bottom line in many ways. The technology architecture layer and the implementation of capabilities and the adoption of standards all fit into the cloud strategy and approach. There are long lists of technical aspects that directly align with performance and ultimately determine service availability, viability and agility and they should be captured in the EA knowledgebase and understood, before the possibility of a cloudburst.
Someone just reading this for the first time might take away that there is a certain prejudice in this article against cloud computing as an approach or strategy for enterprises meeting their future needs. That was not the intent and it should be stated that cloud computing is and has happened, in many instances successfully without any architecting being applied at all. This is not different from any enterprise implementing services and capabilities with out architecting them, not in a cloud but locally or corporately. There are always exceptions that someone can point to, just like we did as children saying, “those kids didn’t have to do it”. I still hear my parent’s response, “you aren’t those kids and you aren’t as lucky as they are.” When the choices are such, that implementing virtual business capabilities in the clouds can be effective, efficient and prudent, meaning they were architected first and that architecture guided their implementation, there need not be fear of a storm on the horizon.
