|
![]() ![]() ![]() |
On one of the global electronic forums on Enterprise Architecture, Kaytek Consulting Director recently had interactions on the Importance of Enterprise Architecture with a Senior IT Manager of one of India's Top Private Sector Insurance Company. This organization's group companies are one of most IT savvy in India both within their insurance vertical and other financial services. Their Group Head looks after the IT function personally to the best of our knowledge as per press reports. These discussions are shown below. ![]() Enterprise Architecture (EA) (and Enterprise Architects) are critical to an organization's information systems functioning for many reasons. A comprehensive EA has to be driven primarily by business drivers. Organizations have life spans that are much longer than individual life times. Also, the current complexity of information systems in an organization necessitates a structured approach to documenting the same. EA provides a uniform conceptual framework that remains consistently true across the organizational life. ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Within each of the above M-Assets , you could have further categories based on your requirements. e.g. One way to further categorize Men (& Women) would be the Types Of Organizational Stakeholders - Owners, Suppliers, Customers, Employees, Regulators & Others. One could do similar categorization for the other M-Assets - the Methods, Money, Markets, Materials, Mortar-Brick, Machines & Messages based on specific business needs. ![]() ![]() Business Architecture would be the structure of the organization (again organized as the above M-Assets resources). Technology Architecture considers the Computing & Communication technology areas (and components) in it's scope. |
![]() ![]() EA should give the means to communicate 'The Architecture of the Enterprise' to all stakeholders. ![]() ![]() Internal Stakeholders could be Business Analysts, Project Manager, User Interface Designers, Database Designers, Programmers, Testers, Implementers, etc. These people should be able to easily use the EA artifacts (or deliverables). They can only do so when EA enables them to communicate at a higher abstraction level than their individual specializations & skills. There are 3 examples of EA's value as a communication platform shown below : ![]() ![]() ![]() ![]() ![]() ![]() I hope the value of EA artifacts as communication vehicles is clear in the context of a software project. ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Many times, enterprise architects debate on whether they should use enterprise data, information or applications as starting points. For non technical senior managers, the above options may perhaps be meaningless. "Where's the beef ? said an old burger advertisement in the US. Similarly, (and especially so in today's ruthless cost cutting environment). Any & every EA initiative must be immediately understood by decision makers as helping achieve one of the 3 business objectives mentioned above. ![]() ![]() Also, these adhoc solution pieces need to be coherently assembled by Enterprise Architects like us into a larger jigsaw puzzle at a higher level. |
EA helps you get both a A Top level Macro Helicopter Perspective & A Detailed Deep Dive Dirty Hands On Operational Issue Handling Capability. It should help you spans the entire stack of the Enterprise Technology and Business Architecture either in a Top Down or a Bottoms Up fashion. ![]() ![]() It helps you work with whatever technologies your organization has invested in or you have the capabilities to work with. e.g. As a building architect, I may design a house for you which does not specify the construction materials that you may use. You may choose to build your house with twigs, stones or bricks. Remember the Kindergarten story of the 3 little pigs ? It is upto you to choose your technology instances or business solutions. A caveat, though. It is always helpful to know technologies in depth so that you can always strive to optimize the technical architecture of your applications as you scale & grow. EA does not depend on specific technologies. e.g. an aircraft designer need not be an airplane pilot or vice-versa. ![]() ![]() ![]() ![]() However, the two (IT strategy & EA consultancy ) are not mutually exclusive. ![]() We have developed proprietary business & technology templates, frameworks that can help your organization achieve it's business goals with EA. Kindly email us for more details. ![]() |
|
|
|
|
|
|