Enterprise Architecture Offshoring - Part 2
In my previous post, I was musing about the increasing significance of Enterprise Architects. Continuing from where I left off, it is interesting to see others also striving to define the Enterprise Architect. There are a lot of different definitions for “enterprise architect.” It can get really confusing, particularly if you follow a lot of blogs written by enterprise architects — and I did.
I came across a few interesting blogs on technology managers and EA. Ed Gibbs blogs on Moving to Enterprise Architecture, the blogs on successful software architecture and Six Sure Fire ways to Sink your Enterprise Architecture also made for an interesting read.
Fact is that work being offshored to/by software services companies is highly technical in nature. Bulk of such technical work involves translating requirements to workable solutions and also to ensure that such solutions continue working according to Service Level Agreements (SLAs) defined by businesses. It is therefore imperative that initiatives get the required oversight from technical experts and stakeholders. Such oversight includes review of architecture and design for use of industry best practices and conformance with the required Quality of Service QoS. The real skill comes in contextualizing the applicability of technology, validating best practices and reuse in the specific business and enterprise context.
In an offshored context, there is no reason one cannot leverage offshore architects for required architectural inputs, review and governance. Thanks to pervasiveness of information about ‘technology building blocks,’ base frameworks and body of knowledge, best practices can be leveraged from across geographies where technical experts may happen to reside.
Bottomline: one can extend the theme from "A Litmus Test for IT" Just as the blog says "a good IT department should be able to describe the business problem – that the company’s definition of a customer is changing – and explain that the project it’s working on will update the systems to reflect that. If the IT guys start talking about a new data warehouse that can rationalize customer records it might be time to worry" An Enterprise architect too should be able to describe the business problem.
- Mohan Babu K.
