Describe Enterprise Architecture

I am looking for the best way to answer the following question - Describe your company's enterprise architecture?
Since majority of customers of my company are scattered all over the country, the best way to deploy information products data-driven software and decision support systems with zero footprint was to use ASP/SaaS model and we have been very succesfull at that. Microsoft .NET is our standard development platform with emphasis on componnet and web services based application architecture with SQL Server as our RDBMS/DW/BI platform. Also we use enterprise level systems from other vendors such as Siebel and Cognos.
I am not sure if this is the right way to answer the question. I would love to hear from you about your thoughts on giving the best, concise, and technically correct answer. How would you describe yours?
Regards,
Victor

Popular White Paper On This Topic

Victor, To me what you have described is an IT Architecture. Your description started with a bit about the business but I did not see anything about what is the strategy of the organization.
Here is what I use as a starting point to describe EA at BCIT:
Enterprise Architecture (EA) is a strategic framework to provide guidance, consultation and approval of investments in people, process and technology that aligns to and supports Institutional Strategy and Vision.
Happy to share more ideas ... also take a look at my blog http://leodesousa.caCheers! Leo

I agree with Leo de Sousa. Your description is that of an IT Architecture. I am not even sure it is part of an "Enterprise Architecture". If what you described is implemented Enterprise Wide than it is only one portion of an Enterprise Architecture.
A description I used for one client who ask a similar question is:
"Our Enterprise Architecture (EA) is focus on Business, Data and Information Technology Enterprise Wide standards, montoring and tracking adherence to the EA. Items that are unique to a functional area is not included in the EA, only those that are to be used throughout the enterprise. (e.g. Human Resource, Payroll, Acquisition and Content Management ) Our EA only addresses the conceptional, contextual, Data and logical views of the architecture. Implementation and detail information is kept by the organizational unit responsible using the product standard for providing that functionality. Our EA provides management a line-of-sight view from conceptual to logical providing decision makers and portfolio managers additional information that will assist in making sound IT investments."
I know this is long winded and normally I use less EA terms, but it takes more than one or two sentences to provide a high level explaination of an organization's EA environment.
I hope this helps. There are many other descriptions since EA environment differs within each organization based upon goals, objectives, priorities and both strategic and tactical plans.

Hi ! You have decribed the architecture without the Enterprise (The forest) . Enterprise Architecture aligns technology with business. it is not just a list of standards. There is a difference between Enterprsie Solution and Enterprsie Architecture. Enterprsie solution is what you have described. Enterprsie Architecture is suppose to show how the applicaiton, data and technology associate to enterprise business.

This is a straight question but without a straight a answer that I know of.

The challenge is how to describe both the enterprise and the architecture. The Light Enterprise Architecture is in the middle to suggest the use of EA topology to render Enterprise Architecture. Your question comes in the right time, hopefully working together, we can come up a way to describe EA in a nut shell without confusing our customers . The question is the Enterprsie Architects common challenge.

What you describe is an IT architecture, or even a service-oriented
architecture. An enterprise architecture, using your scenario, would
describe the processes that drive a diversified company, the systems,
networking, and communications that support the processes, and the
services links to customers--all at the company level.

Enterprise Architecture is still a tricky area to describe. First off, if that is your enterprise, then so be it, you have to define the scope of what your enterprise is first... so it sounds like you want to create an EA that is based upon your area of knowledge, SQL Server and the apps above it. This is not quite the way to do it, but you can go from information, business or application architecture towards Enterprise Architecture, but take some time to figure out why you want to do it.

There is typically one primary reason for EA. Explain in Business Terms at a Conceptual Level how the Enterprise is leveraging technology to fulfill its business goals and strategies.

This is typically a pivot between the Technology Infrastructure diagrams, UML Acitivy Diagrams, Business Process Flow Diagrams, with a layer above them to help describe what you want to change and WHY. That is a reason for doing EA, to create an change plan and show 'application revitalization areas' that have been sitting in old hardware in unsupported technologies...

more than happy to chat about this more, its what i do for a living...

the way to describe your EA in the context talked about i would say,if u
understand your company operating model in terms of standarization
+integration requirements then you understand that the ea is directed
towards achievement of a final goal.The EA description will be summary
of the roadmap you have charted out to cretae an agile orgnaization.
Keep it simple not bogged down by buzzwords of all other IT initiative
bloating causes of speed to market,agility,etc.If you can visualize what
the end state of an EA looks like for the organization at this point in
time because there are maturity stages for the enterprise both
businesswise and IT wise then you will be in a better way to describe an EA.
This is my two cents in this community.Would also be great if others
contribute and make me understand that what I say is upto the mark.
Sanjeev Tandon
senior Manager-IT
ICICI Prudential,kandivali Hub.
Mob#9867226592

I agree largely with what "pryslak" has said below. I would amend it to
read as follows, to make his explanations applicable to those who pursue an
EA that has a broader focus than just IT.

. you have to define the scope of what your endeavor is first
. There is typically one primary reason for EA. Explain in Business
Terms at a Conceptual to Detail Level how the Enterprise is leveraging its
resources to fulfill its business goals and strategies.
. That is a reason for doing EA, to create a change plan and show
'capability revitalization areas' that have been applying old methods using
unjustified or obsolete resources.

By way of analogy, I have found that getting those who "live in the IT
village", and thus having an IT viewpoint, have a very hard time broadening
their perspective to abstractly perceive the "whole valley of
resource-specific villages" within the organization's domain.

I take this "whole-endeavor" approach because IT is a subcategory of
"Materiel" resources, which is a subcategory of "Resources". In an
enterprise "Resource" catalog (also called a resource Inventory, resource
reference model, or resource taxonomy), IT is a very small part of the
resource collection that an EA can be used to describe, justify, and govern
in pursuit of an organization's mission, vision, goals, and success
indicators. As illustration, see my diagram at
http://www.one-world-is.com/rer/owis/gem-core/bitmaps/Slide499.JPG.

I have found that Enterprise Architecture over time has changed from being
an IT discipline, typically, to that of a facility to develop and execute
business strategies. It encompasses the vision, mission, goals and
objectives of an Enterprise (either all of it or parts of it), and the
infrastructure components (organizations, positions and people, applications
and technologies) required to successfully execute business strategy, which
is what Executives do. Recently the term Actionable Enterprise Architecture
(AEA) has been used more and more to describe the dynamics involved in
transforming the Enterprise from a current state to a future state, again,
this means executing business strategies.

There are multiple ways of looking at this and expressing it, and it depends on which model you use - some methodologies effectively include development of the SIP, others do not cover it at all.

To my way of thinking, EA provides a range of artefacts which contribute to the development of a SIP. I have a tendency to be rather black and white and purist - in that vein, the architectures simply describe current and future - where as SIP covers how to get there, priorities, investment, risk, etc. So, they are closely related and, I can say, that in recent work I have done in developing SIPs, incorporating an EA approach to understanding the current and future business environment and then the applications and infrastructure which will be required, has enhanced the SIP process.

Rajiv,
EA spans much more than information, information systems and applications.
It covers all aspects of how a business operates. A SIP can be a sub-set of
a well developed and maintained EA, and usually defines the slate of
projects that need to be executed over the next 2 - 4 years in order for the
enterprise (however that is defined) to provide information for operations
and executive decisions. The SIP typically deals with processes, systems,
information (data and reports), and who use the information. A SIP is
aligned with business strategy.

About Victor's company's enterprise architecture.
What is the best, concise, and technically correct way to describe it?
Is it really that difficult?
This feels like a 15 minute architecture exam question.
Victor's message contains the answer.

There can't be a universal answer, without a universal definition of EA.
Some EA frameworks are description centric, some are process centric.
Most would say that EA responds and maps to a business strategy.
But a strategic information plan surely only makes sense in relation to
information/data architecture.
So yes, a Strategic Information Plan is surely best considered one (not
only) output of EA.

totally agree. i am currently creating a part of an EA for a government customer that is going to use it for their SF 53, which will help them forecast for their 2010 budget requests to OMB through an OMB 300 doc... so there is definitely a flow to all of this, but it changes based on the organization and what it see's as 'resources'.

Greetings All:
I am new to this group but I find this discussion extremely exhilarating
with regard to the whole IT infrastructure, and specifically the EA
environment. I am into IT security and routinely review Government IT
architectures for their compliance with OMB and other security regulations.
Roy's explanation of expanding the EA "to make explanations applicable to
those who pursue an
EA that has a broader focus than just IT" is right on the mark and in line
with such frameworks as CobiT, COSO, and others that seek to align business
with the EA environment.
Service Oriented Architecture (SOA) is a perfect example of Roy's statement
of "That is a reason for doing EA, to create a change plan and show
'capability revitalization areas' that have been applying old methods using
unjustified or obsolete resources".
In addition, the "whole - endeavor" based approach which Roy has espoused,
is also a basis for doing a Risked Based System Security plan. This plan
utilizes all of the identified inventory in identifying Threats and
Vulnerabilities and determining the likelihood of those vulnerabilities
being exploited. This entails looking at the "Impact levels" of those those
vulnerabilities if they are exploited and drives the Business Impact
Assessment and Security Testing and Evaluation of these EA systems. These
assessment of systems then drive the Disaster Recovery Plan (DRP),
Continuing Operations Plan (COOP) and other assessments.
Thanks for these intelligent posts, it is good for stimulating thought and
well needed to keep us all on our toes and sharp.

Your explanation only covers a very small portion of Enterprise Architecture. You provide information of the 'what' portion that is associated to the IT element of the enterprise. Nowhere is there mention of the business element of the enterprise. A well-defined presentation will provide the WHAT, HOW, WHERE, WHO, WHEN and most important WHY of both the business and IT elements of the enterprise.

Based on the strategic plan(s) and model(s) of the enterprise, clear expressions of requirements are created by the planners and owners of the enterprise which are supplied to the enterprise architects for design and implementation.

The utmost importance to the enterprise architecture is top-management buy-in, support, and commitment to change of the architecture.

Copyright 1998-2015 Ziff Davis, LLC (Toolbox.com). All rights reserved. All product names are trademarks of their respective companies. Toolbox.com is not
affiliated with or endorsed by any company listed at this site.