Infosys’ BPM-EAI blog offers a platform to discuss the latest trends in the Business Process Management and Enterprise Application Integration spaces. Exchange thoughts, ideas and opinions with Infosys experts on how BPM and EAI programs can be leveraged to achieve operational excellence and maximize your return on investment.

« January 2009 | Main | December 2009 »

October 26, 2009

How does the Cloud Computing story affect Enterprise Architecture?

The T-Mobile’s wonder toy Sidekick has recently been in the news for all the wrong reasons. For the uninitiated, the Sidekick is a Smartphone meets Iphone (no puns intended) device which boasts of a whole plethora of tools and features for the mobile generation making it an affordable wireless e-mail/phone/PDA hybrid.

Earlier this month, T-Mobile announced to the Sidekick’s users that all of their data has been lost, and attributed it to a server failure at Microsoft’s (yes.. they own the platform) Danger subsidiary. The fiasco has of course over shadowed the the total data loss at Ma.gnolia earlier this year, which had been the existing benchmark for user data evaporation.

The fact that the platform never had a more robust disaster recovery strategy is something that most analysts are finding difficult to accept. Well, given that the data center was not owned by the actual consumer service provider (T-Mobile), is leading them to comment that this undermines the reliability of the entire concept of Cloud Computing. ZDNet called it “one of the biggest cloud computing disasters so far.” Cnet wrote that the incident “threatens to put a dark cloud” over Microsoft’s cloud ambitions.

While I don’t really participate in this doomsday prognosis, this does highlight that the key enterprise architecture best practices are still relevant irrespective of the ownership pattern of the solution components. In this case, the consumer (T-Mobile), never paid for a disaster recovery SLA and hence they never got it. So, the miss would really be on the part of the consumer than the service provider. 

I believe, the basic hypothesis of Cloud Computing bears an uncanny resemblance to the old (ancient ?) paradigm of Application Service Providers (ASPs), and that’s a connection that should not be lost while we try to decompile the jargon around us. One of the unfortunate offshoots of the recent hype generated by Cloud Computing is that most IT professionals are finding it difficult to visualize this connection. Buying v/s Building has been an issue that most organizations have been grappling with for the last many years and going the “cloud” way has often been seen as an extension of that approach.

However, I believe, we need to understand that buying services and platforms doesn’t really absolve the enterprise from key responsibilities of defining, governing and owning the Enterprise Architecture. With the SLA based approach, where most platform providers promise you that you get what you pay for, it becomes ever more important that your shopping list has been deliberated upon thoroughly. This move towards commoditization of the enterprise platform, essentially means that the onus shifts back on the EAs to keep a tighter watch on what they are buying and using.

Some of the Key areas where the role of EA will become much more relevant are :

Business Architecture
The evolution of the enterprise’s business will continue and the EA will need to analyse and cater to impact of that on the overall architecture (this greatly depends on what components are pushed out). The move to the Cloud might provide the agility required to respond to this change, but that will need to scrutinized and managed closely.

Information Architecture
Again, the role of the EA will continue to be crucial to ensure the capture, processing and reporting of business critical information throughout the enterprise. While the actual control over some parts of the information model may depend on the way the data resides across the cloud components and the on-premise components, the overall ownership has to be with the enterprise.

Policy & Risk Architecture
With the increased chatter going out the enterprise gateway, there will be an increased focus on ensuring the robustness of the external communications gateway. This will be less towards the actual technical communication, since most of that will get consolidated towards industry standards, but more towards security and policy enforcement across the enterprise. It will require architects to figure out the right solutions for identity management, data at rest security, transactional security, and physical security. At the end of the day the enterprise is ultimately accountable for the data stored in a SaaS data center.

In conclusion, the fact that the platform has been federated on either ends of the enterprise gateway, shouldn’t in anyway undermine the role of the Enterprise architects. Overall governance and ownership is going to be as important as ever, irrespective of how we federate the actual solution components across the enterprise or outside it.

Agile SOA approach

Service-oriented architecture (SOA), has become a familiar term for architecture community in the last few years. The paradigm of business users creating application functionality was too exciting to ignore. This was done through building and managing business processes, all hosted on an enterprise service bus – thus disentangling the integration spaghetti forever.

However, with tragic tales of SOA projects failing to live up to the hype, the time phenomenon has highlighted that a light and agile methodology might be the way forward as opposed to traditional approaches.

Most service based solutions have been based on the proverbial holy grails such as Enterprise wide Canonical Data Model and Service Bus. However, the next wave would require a shift towards more efficient variants that are tailored to the specific needs of business, with prioritization based on market dynamics, enterprise inertia, business priorities, investment strategy, and ROI..

Skipping the Canonical Data Model to move towards a federated MDM strategy and a brokerage approach to communication between systems is the way forward. This should ideally be based around a distributed data strategy that leaves information in the source systems but provides references between them. Consider the impossibility of imposing the Canonical Data Model on the software-as-a-service (SaaS) providers and the virtue of this approach becomes apparent.

Similarly, the Enterprise Service Bus is a myth as well. The entire enterprise will never get on a single ‘bus’. This is primarily since there never will be a business case strong enough pull funding for the strategic service model on legacy systems. A more pragmatic approach would be to divide the enterprise bus into two logical sections. These are, the Clean Data Bus that hosts enterprise services adhering to the enterprise service framework, and the Dirty Bus to host specific services for legacy and non-adhering systems. The dirty bus clearly scores over the erstwhile point-to-point integration, offering greater control over auditing, logging and exception handling.

To define the SOA roadmap well, it is critical to understand that it is not just about processes or services definition but also technology and people that will make or break the initiative. For an organization to adopt this strategy, it needs to be mature enough to take the risk of initial investment. Organizations with a clear focus on implementation will reap long-term benefits.

Note: The above post has been based on an article co-authored by me on the same theme to be published soon.