Job description

mapping of I/T capabilities to business needs.

defining the relationships, flows and implementation of business processes/activities/functions,

information), applications, data and technology in the enterprise and the transitional process
necessary for implementing technology in response to changing business needs.

the technical team lead and the client-facing technical visionary.

As the technical lead, the Solutions Architect partners with Program/Project Management Leader,
guides and executes the technical delivery strategy during deployment.

In role of the visionary, the architect supports pre-sales and follow-on strategies by working with
functional leadership, partners and the client to define valuable solutions leveraging IBM SOA
Products & Frameworks.

Responsibilities:
* Provide technical leadership to consulting project teams, leading architecture workshops and also
include project work at customer sites.
* Design and develop innovative solutions to customer requirements using our IBM WebSphere
Dynamic BPM Platform (including Fabric) and Telecom Operations Content Pack. This WILL require
hands-on knowledge with the product stack.
* Strong knowledge of the telecommunications industry, various standards, competitor products,
benchmarks and compatibility.
* Provide consultative leadership to clients and prospects
* Participate in the pre-sales process to understand customer business, technical objectives and
product requirements, in order to develop effective solutions.
* Assist Program Manager with the definition of tasks, deliverables and standard estimates.
* Help to document best practices in developing and deploying IBM SOA/BPM solutions, and feed
them into our knowledge base for reuse by customers and partners.
* Mentor and recruit technical consulting staff.
* Participate in customer requirements gathering, design review, acceptance testing and
deployment processes, and produce quality deliverables accordingly.

Required Qualifications:
* 10+ years of software design/development experience. Five years in Java/J2EE environment and
at least three years of customer facing experience in that capacity.
* Hands-on experience in designing, implementing and managing loosely coupled SOA and
integration solutions with IBM WebSphere Middleware Stack.
* Knowledge of TeleManagement Forum Standards including eTOM, SID, TAM, TNA, OSS/J.
* Strong skills in Logical Data modeling, Physical Data modeling and development of a data strategy
and associated polices.
* At least five years experience in customer-facing positions as a member of a professional services
or pre-sales organization for a software product company.
* Strong EAI and/or web services background, ideally in the telecommunication industries.
* Experience and familiarity with enterprise integration technologies for large, complex IT portfolios.
Strong understanding of enterprise customer IT operational issues and challenges.
* Experience with modern software development methodology's, with emphasis on SOA and Web
services preferred.
* At least three years experience in a technical lead role for technical teams of five or more. Mixed
delivery models with offshore development is a plus.
* Hands on knowledge with WebSphere Integration Developer, WebSphere Process Server,
WebSphere Enterprise Service Bus. WebSphere Business Services Fabric is a plus.
* Experience with SOAP, WSDL and other web services technologies. Java experience should include
J2EE, JMS, EJB, and JDBC.
* Experience with Rational Software Architect and/or similar software modeling tools
Key Role:
Serve as the primary client lead and advisor in interfacing with senior-level EA clients,
helping to shape the vision, direction, priorities, capabilities, and plans for EA programs.
 Lead project staff teams in providing full life-cycle EA support, including baseline
development, target development, transition planning, implementation, and segment
architecture, EA governance, EA program management, and EA communications.
Provide EA integration with related disciplines, including IT portfolio management,
systems engineering, IT security management, business and IT strategy development, and
EA tool selection, use, and management.
Direct teams in advanced modeling and analytics across all architectural layers or views
for large and complex organizations, including strategy, business, data, applications,
systems and services, technology, and security.
Develop, select, or adapt appropriate EA methodologies, frameworks, and approaches
to address client objectives and drive EA toward business results.
Facilitate stakeholder work sessions focused on making enterprise-wide decisions that
balance and prioritize competing interests of individual stakeholder groups.

Communicate the value and relevance of EA to senior business executives or program

officials.

Qualifications

Basic Qualifications:
-7+ years of experience with IT
-3+ years of experience in using Enterprise Elements
-3+ years of experience in project management and IT Governance
-3+ years of experience with DODAF methodologies
-3+ years of experience in modeling with structured analysis, UML
-Experience with other EA methodologies and frameworks, including FEA and
TOGAF

Enterprise Architect

• Responsible for providing architectural vision for all IT systems, including those that
support Internet applications, ensuring that architecture conforms to enterprise blueprints.
• Develops architecture, strategy, planning, and problem solving solutions on an
enterprise level.
• Interfaces across several channels, acting as a visionary to proactively assist in defining
direction for future projects.
• Maintains continuous awareness of business, technical, and infrastructure issues and
acts as a sounding board or consultant to aid in the development of creative solutions.
• Depending on project scope, may be accountable for end-to-end results including such
items as: budgeting, policy formulation as well as providing future-state technology
-strategies for an effort. • Interfaces with vendors to assess their technology and to guide
their product roadmap based on Citi requirements.

• Provides thought leadership in subjects that are key to the business.

• Requires sophisticated analytical thought to resolve issues in a variety of complex
situations.
• Impacts the technology function through contribution to technical direction and
strategic decisions.
• Uses developed communication skills to negotiate and often at higher levels.

Qualifications

Advanced level experience in an Architecture role.

Subject matter expert in overall Architecture field.
Both technical breadth and depth.
Industry relevant experience capital markets front and back office and other financial
transaction offerings.
The Architect is a key technical and/or functional leadership role within the segment.
The Architect is typically a sub-system, functional or product(s) architect.
Architects provide expert guidance and support to the development organization in
various technical/functional aspects of research, development and engineering.

* Functional decomposition of system architecture into subsystems

* Architectural design of subsystems while adhering to system’s architectural constraints
* Leverage Enterprise Design Patterns for architectural excellence
* Manage design evolution across multi-generation product releases
* Communicate design to development teams and guide implementation
* Leveraging technical and clinical depth to work on business initiatives aimed at
innovation and quality excellence
* Developing subsystem roadmaps applying in-depth knowledge of product related
technologies, technology platforms, architectures and engineering design principles and
advancements
* Leading the subsystems technical teams through the entire design cycle including
requirements generation, design and implementation, verification & validation as the key
technical mentorQualifications/Requirements* Bachelors degree in Engineering or
related field
* 7 years relative engineering experience
* Practical experience in engineering product development processes on cross-functional
programs with a focus on related engineering discipline
* Familiarity with Variable Cost Productivity (VCP) and Inventory Carrying Value (ICV)
* Demonstrated ability to influence product leadership and product direction through
action-oriented recommendations based on technology strategy and risk retirement
* Good written and oral skills
* Must be willing to work in our Salt Lake City, UT facility full-time
* Must submit application for employment through gecareers.com (or COS if internal) to
be consideredAdditional Eligibility QualificationsGE will only employ those who are
legally authorized to work. Any offer of employment is conditioned upon the successful
completion of a background investigation and drug screen.Desired Characteristics*
Masters or PhD in Engineering or related field
* 8 years relative engineering experience
* Demonstrated expertise in specified area of interest with the ability to develop
engineering specifications for major sub-systems/sub-assemblies, written reports on
technologies, and other product design recommendations
* Demonstrated experience on global product releases throughout the entire NPI cycle
* In-depth working knowledge of patient/customer product-related clinical applications
and scientific/engineering methods/theory with an affinity for technology and clinical
solutions
* Demonstrated ability to work in a collaborative fashion with cross-function
development teams and architects

Perficient, Inc. is seeking an experienced B2B Enterprise Architect for a key role with
our Dallas-based consumer products client. The candidate will have the following
responsibilities:

• Accountablility for the quality of the architecture and designs of a solution

• Review the architectural needs of the project, validating scope, architecture
resource needs, and total cost of ownership
• Responsible for infrastructure architecture deliverables including conceptual,
directional, logical, and physical architecture and design documents
• Responsible for growth, performance, flexibility, reliability, scalability, and
security of a solution
• Responsible for adherence to architectural standards and compliance
with Enterprise architecture and Security policies
• Provide technology architecture consultation to development, baseline
(operations), enterprise test, infrastructure, and engineering teams
• Create and document architecture artifacts when in the role of a project architect,
with a focus on architectural standards, growth, performance, flexibility,
reliability, scalability, and security
• Participate in RFP’s (when applicable) and evaluate the solution for adherence to
our client's standards
• Provide guidance on integration and architecture to third party professional
service providers and ISVs
• Identify patterns, reusability opportunities, and promote them across the
enterprise using the CTO and Enterprise Architecture channels.
• Responsible for architecture of IT technical areas across application network,
server, database, application integration and virtualization technologies.
• Estimate software, labor and hardware costs across multiple IT Technical areas
• Review other application team or vendor architectures, identifying risks with the
application integration approach, tool choice, information security and sizing.
• Consult on production issues and driving root cause analysis and remediation.
• Build executive level presentations on architectural direction, options and solution
cost benefit analysis
The ideal candidate will have the following skills/experience:

• Experience with the design, implementation, and operation of B2B Gateways

• Experience with EDI and other B2B standards
• Experience in infrastructure, middleware, large data movement, dashboards,
reporting, data marts, security, and application and report development and data
marts
• Solid technical aptitude, leadership, mentoring, and customer facing skills
• Experience with solution and application infrastructure including Windows and
Linux, VMWare, Storage Arrays, application server, web servers, networks, load
balancers, and firewalls
• Experience with Enterprise Application Integration (EAI) based solutions and
EAI tools such as TIBCO EMS/BW
• Experience with Extract, Transform, and Load (ETL) based solutions and ETL
tools such as Informatica PowerCenter, Ab Initio, or large file transfer tools
• Experience with databases such as SQL Server, Oracle, or DB2 and data
modeling
• Experience with capacity planning, sizing, and load balancing in a distributed
application environment
• Experience with high availability and disaster recover techniques and
technologies
• Experience in designing and overseeing the implementation of highly fault
tolerant solutions using high availability and/or disaster recover techniques and
technologies.
• Experience with authentication, authorization, and single sign on
• Solid understanding and experience in virtualization technologies for Windows
and Unix platforms
• Understands application, third party software, and database licensing constraints
models and cost implications
• Experience in the full project life cycle that requires leading teams through
architecture for technology and infrastructure (Servers, Virtualization, Storage)
• Strong analytical skills, oral and written communication skills
• Past history of building relationships with a wide range of individuals
including CTOs/CIOs, solution architects, application architects, project
architects, development leads, project and program manager, and enterprise test
teams
• Strong Leadership and time management skills
• The ability to communicate complex technical topics and analyses to technical
and not-technical executives

Allstate Architecture Standards and Methods (AASM)

BearingPoint Configure To Fit Method
BearingPoint Methodology
Bredemeyer VAP
CA Solution Architecture Methodology
CSC Catalyst
Capgemini Integrated Architecture Framework (IAF)
Credit Suisse IT Solution Framework
EDS GSMS/GAD QMS
Enterprise Solution Delivery (ESD)
GM System Delivery Process (SDP)
HP Global Method for IT Strategy and Architecture (HPGM for ITSA)
IBM Global Services Method
IBM Team Solution Design
IMPACT (TCS Architecture Development Methodology)
Intel AEPF Intel IT Architecture Development Methodology (Intel IADM)
New Zealand Inland Revenue - IR Method
Rational Unified Process (RUP)
Raytheon Enterprise Architecture Process (REAP)
SUN Architect Implement and Manage (AIM)
TOGAF 7
TOGAF 8
TOGAF 9
Telstra Technology Delivery Process (TDP)
TelstraClear Infrastructure Lifecycle Process (ILP)
UPS Solution Architecture Process

Enterprise architects use various business methods, analytical techniques and conceptual
tools to understand and document the structure and dynamics of an enterprise. In doing
so, they produce lists, drawings, documents and models, together called "artifacts". These
artifacts describe the logical organization of business functions, business capabilities,
business processes, people organization, information resources, business systems,
software applications, computing capabilities, information exchange and communications
infrastructure within the enterprise.

A collection of these artifacts, sufficiently complete to describe the enterprise in useful

ways, is considered by EA practitioners an 'enterprise' level architectural description, or
enterprise architecture, for short. The UK National Computing Centre EA best practice
guidance[7] states

Normally an EA takes the form of a comprehensive set of cohesive models that describe
the structure and functions of an enterprise.

and continues

The individual models in an EA are arranged in a logical manner that provides an ever-
increasing level of detail about the enterprise: its objectives and goals; its processes and
organisation; its systems and data; the technology used and any other relevant spheres of
interest.

This is the definition of enterprise architecture implicit in several EA frameworks

including the popular TOGAF architectural framework.

An enterprise architecture framework collects together tools, techniques, artifact

descriptions, process models, reference models and guidance used by architects in the
production of enterprise-specific architectural description.

See the related article on enterprise architecture frameworks for further information.

In 1992, Steven Spewak described a process for creating an enterprise architecture that is
widely used in educational courses

Several enterprise architecture frameworks break down the practice of enterprise

architecture into a number of practice areas or "domains". In his book on Enterprise
Architecture, Spewak divides the practice into two domains at 'level 2': "Business
Modelling" and "Current Systems and Technology" and three subordinate domains at
'level 3': "Data Architecture", "Applications Architecture" and "Technology
Architecture". The final level of Spewak's EAP is the "Implementation" or "Methods"
level, which deals with "how" to migrate the Enterprise to match the new model.[9]

The popular TOGAF framework divides the practice into three domains: "Business
Architecture", "Information Systems Architecture" and "Technology Architecture" and
then subdivides the information systems architecture into "Information Architecture and
"Applications Architecture".[10]

The Strategic Architecture Model allows for a flexible division into up to ten domains
covering many aspects of an enterprise from its objectives and goals through its projects
and programmes to its software applications and technology.[11]

The dividing of the practice into a number of domains allows enterprise architects to
describe an enterprise from a number of important perspectives. This practice also
encourages the contributions of many individuals and allows the practice as a whole to
make good use of individual domain-specific expertise and knowledge. By taking this
approach, enterprise architects can ensure a holistic description is produced.

The popular and most common four domains and their component parts look like this:

1. Business:
1. Strategy maps, goals, corporate policies, Operating Model
 2. Functional decompositions (e.g. IDEF0, SADT), business capabilities and
organizational models expressed as enterprise / line of business
architecture
3. Business processes, Workflow and Rules that articulate the assigned
authorities, responsibilities and policies
4. Organization cycles, periods and timing
5. Suppliers of hardware, software, and services
2. Information:
1. Information architecture - a holistic view on the flow of information in an
enterprise
2. Metadata - data that describes your enterprise data elements
3. Data models: conceptual expressed as enterprise information architectures,
logical, and physical
3. Applications:
1. Application software inventories and diagrams, expressed as conceptual /
functional or system enterprise / line of business architectures
2. Interfaces between applications - that is: events, messages and data flows
4. Technology:
1. Inter-application mediating software or 'middleware'.
2. Application execution environments and operating frameworks including
applications server environments and operating systems, authentication
and authorisation environments, security systems and operating and
monitoring systems.
3. Hardware, platforms, and hosting: servers, datacentres and computer
rooms
4. Local and wide area networks, Internet connectivity diagrams
5. Intranet, Extranet, Internet, eCommerce, EDI links with parties within and
outside of the organization
6. Operating System
7. Infrastructure software: Application servers, DBMS
8. Programming Languages, etc. expressed as enterprise / line of business
technology architecture.
The three components of the enterprise architecture framework are:[2]

• Views : provide the mechanisms for communicating information about the

relationships that are important in the architecture
• Methods : provide the discipline to gather and organize the data and construct the
views in a way that helps ensure integrity, accuracy and completeness
• Training/Experience : support the application of method and use of tools

Because the discipline of Enterprise engineering and Enterprise Architecture is so broad,

and because enterprises can be large and complex, the models associated with the
discipline also tend to be large and complex. To manage this scale and complexity, an
Architecture Framework provides tools and methods that can bring the task into focus
and allow valuable artifacts to be produced when they are most needed.

Architecture Frameworks are commonly used in Information technology and Information

system governance. An organization may wish to mandate that certain models be
produced before a system design can be approved. Similarly, they may wish to specify
certain views be used in the documentation of procured systems - the U.S. Department of
Defense stipulates that specific DoDAF views be provided by equipment suppliers for
capital project above a certain value.

Enterprise Architecture started with the Zachman Framework in 1987. Another early
implementation of an Enterprise Architecture framework was the "Technical Architecture
Framework for Information Management" (TAFIM). The first draft of TAFIM was
completed in 1991 with the TAFIM Technical Reference Model (TAFIM TRM). This
technical reference model wanted to use open systems and new technologies available in
the commercial market, to develop a DoD-wide application.[3] The TOGAF TRM was
originally derived from the Technical Architecture Framework for Information
Management (TAFIM), which in turn was derived from the IEEE model 1003.0[4] or
POSIX Open System Environment: a standard "to construct an information processing
system, including consumers, system integrators, application developers, system
providers, and procurement agencies".[5]

In recent years, it has become apparent that a key benefit to be gained from Enterprise
architecture is the ability to support decision making in changing businesses. Because
Enterprise Architecture brings together business models (e.g. process models,
organizational charts, etc.) and technical models (e.g. systems architectures, data models,
state diagrams, etc.) it is possible to trace the impact of organizational change on the
systems, and also the business impact of changes to the systems.

As this benefit has emerged, many frameworks such as DoDAF, MODAF, or AGATE
have adopted a standard meta model which defines the critical architectural elements and
the dependencies between them. Applications based on these models can then query the
underlying architectural information, providing a simple and strong mechanism for
tracing strategies to organizational and technological impacts.

Layers of the Enterprise Architecture

Contemporary federal guidance suggests thinking about “layers” of the enterprise

architecture:[9]

• Business processes and activities

• Applications such as custom or off-the-shelf software tools
• Data that must be collected, organized, safeguarded, and distributed
• Technology such as computer systems and telephone networks

The Architecture Domains follow a pattern of decomposition as one goes from top to the
bottom of the framework. The ownership can be divided into 4 broad categories:
planner's view, owner's view, designer's view and developer's view in this order. All the
views are mostly hierarchical in nature. For business view the planner and owner's level
is typically called the value chains (which are descriptive by nature). The designer's view
of business is also known as the analytical view and there are various standards for
modeling this view. One mostly commonly used modeling standard is the Business
Process Modeling Notation (BPMN). The designer's view typically represents the
execution level which uses standards like Business Process Execution Language (BPEL).

Enterprise Architecture Domains and Subdomains

The Application and Technology Domains (which are not to be confused with business
domains) are characterized by domain capabilities and domain services. The capabilities
are supported by the services. The application services are also referred in Service-
oriented architecture (SOA). The technical services are typically supported by software
products.

The data view starts with the data classes which can be decomposed into data subjects
which can be further decomposed into data entities. The basic data model type which is
most commonly used is called ERD (Entity Relationship Diagrams, see Entity-
relationship model). The Class, subject and entity forms a hierarchical view of data.
Enterprises do have millions of instances of data entities.

The Enterprise Architecture Reference Traditional Model offers clear distinction between
the Architecture Domains (Business, Information/Data, Application/Integration and
Technical/Infrastructure). These domains can be further divided into Sub domain
disciplines. An Example of the EA Domain and Sub Domains is in the image on the right.

Many Enterprise Architecture Teams consist of Individuals with skills aligned with the
Enterprise Architecture Domains and Sub Domain Disciplines. For Example : Enterprise
Business Architect, Enterprise Information Architect, Enterprise Application Architect,
Enterprise Infrastructure Architect, etc.

An Example of the List of Reference Architecture Architecture Patterns in the

Application and Information Architecture Domains are available at Architectural pattern
(computer science)

Consortia-developed frameworks

• EABOK (The Guide to the Enterprise Architecture Body of Knowledge) - a U.S.

Federal-funded guide to EA in the context of legislative and strategic business
requirements.
• Generalised Enterprise Reference Architecture and Methodology (GERAM)
• IDEAS Group - a four-nation effort to develop a common ontology for
architecture interoperability
• RM-ODP - the Reference Model of Open Distributed Processing (ITU-T Rec.
X.901-X.904 | ISO/IEC 10746) defines an enterprise architecture framework for
structuring the specifications of open distributed systems.
 • TOGAF - the Open Group Architecture Framework - a widely used framework
including an Architectural Development Method and standards for describing
various types of architecture.
• Good enough architecture methodology - a methodology based on experiences,
results and best-practices gathered through real-life implementations of various
building blocks that altogether provide a realizable architecture and working
solutions.
• ARCON - A Reference Architecture for Collaborative Networks - not focused on
a single enterprise but rather on networks of enterprises [10] [11]

[edit] Open Source Frameworks

• TRAK - a general systems-oriented framework based on MODAF 1.2 and

released under GPL/GFDL.
• MEGAF is an infrastructure for realizing architecture frameworks that conform to
the definition of architecture framework provided in the ISO/IEC 42010 standard.

[edit] Commercial frameworks

• Solution Architecting Mechanism (SAM) - A coherent architecture framework

consisting of a set of integral modules. [12]
• Integrated Architecture Framework (IAF) - from Capgemini company in 1993
• CLEAR Framework for Enterprise Architecture - Atos Origin's Enterprise
Architecture Framework
• OBASHI - the OBASHI Business & IT methodology and framework
• Information FrameWork (IFW) - conceived by Roger Evernden in 1996
• Zachman Framework - an architecture framework, based on the work of John
Zachman at IBM in the 1980s
• The Enterprise Framework - an architecture framework, developed by Sam
Holcman at the Enterprise Architecture Center of Excellence ([1])

[edit] Defense industry frameworks

• DoDAF - the US Department of Defense Architecture Framework

• MODAF - the UK Ministry of Defence Architecture Framework
• NATO Architecture Framework
• AGATE - the France DGA Architecture Framework
• DNDAF - the DND/CF Architecture Framework (CAN)

[edit] Government frameworks

• Government Enterprise Architecture (GEA) - a common framework legislated for

use by departments of the Queensland Government
• FDIC Enterprise Architecture Framework
• Federal Enterprise Architecture Framework (FEAF) - a framework produced by
the Office of Management and Budget for use within the U.S. Government
 • NIST Enterprise Architecture Model
• Treasury Enterprise Architecture Framework (TEAF) - a framework for treasury,
published by the US Department of the Treasury in July 2000.[13]
• Nederlandse Overheid Referentie Architectuur (NORA) - a reference framework
from the Dutch Government E-overheid NORA

UML Modeling

Features

• Latest UML 2.3 specification

• XMI 2.1 import and export
• Reporting in HTML and RTF
• MDA transformations
• Profiles and Technology support
• Testing, resource tracking, maintenance
• Reverse engineer source code in 10+ languages
• Import database schema
• Visualize XSD and WSDL source
• Import .NET and Java binaries
• From single users to large teams
• Repository support for major DBMSs
• Fast to load, fast to use even with large models
• Shareable files or Repository based models
• Version control with any SCC compliant tool
• Role-based security built-in

• Enterprise Architect 8
o Product Details
o Purchase & Pricing
o Compare Editions
o Video Tour
o Success Stories
o Resources
o Enterprise Architect User Guide
• Sparx Systems Community

Join the community today

white papers • tutorials • resources • case studies

• Standards
o UML 2.3
o SysML
o BPMN
o UPDM
o TOGAF
o Zachman
o DDS
• Integration
o Eclipse
o Visual Studio
o TcSE
o DOORS
o Visio
o XMI
o Version Control Tools
 • UML Tools for the Enterprise
o UML Tutorial
o Business Process Modeling
o MDA
o SOA
o SOMF
o Software Design
o Profiles and Technologies
• Support
o Trainers
o Resellers
o Forum
o Report a Bug
o More...

“It’s a unique personality—negotiation skills as well as technical skills,” says John

Ericksen, chief operating officer and leader of technology and corporate services with
PNC Financial Services Group (PNC). “They're hard to find.”

Matson Navigation established an enterprise architecture group in 2004. One of its

biggest contributions to date has been to spread respect for the company’s architecture
and applications standards to application developers and quality testers, says Srini
Cherukuri, senior director of IT operations.

With that understanding, the company moved away from building isolated systems that
perform specific jobs and toward sharing and reusing pieces of applications and business
processes to make IT a more coherent whole, Cherukuri says. That ability to persuade
others to change is critical, he adds. The best architects also understand what kind of data
brings the most value to the company and then influence the design and integration of
systems to produce that data faster, in different combinations and for different
constituencies.

You need people who understand business and customer needs, Ericksen adds. They also
should have broad knowledge of technology capabilities, though not necessarily code and
query languages, he says.

Companies usually look for IT professionals with 10 to 15 years of experience in order to

find that combination of characteristics. Some companies even want their architects to
have a master’s or doctorate degree in computer science or engineering.

Computerworld — A successful enterprise architecture project can help unlock an IT

department's true value to the business it supports. EA, as a discipline, allows an
organization to compare its near-term business objectives with its current technological
capabilities and then make intelligent decisions about what it can reasonably expect to
accomplish. Furthermore, the gaps that are identified represent opportunities for future IT
investments.
Sound like a lofty endeavor? It is, but getting there isn't as difficult as you might think.

Developing a good enterprise architecture program shouldn't require a dedicated full-time

staff of specialists. A team led by a strong, focused manager can jump-start an EA
program by creating small deliverables that the business stakeholders can understand.
(Hint: If your program's objectives can't be described in an elevator speech, have your
team step back and simplify.)

Work with representatives from the business side to set up four easily understood
documents; if the business people have a chance to offer input, they should be able to
understand the business value of each phase of your EA program.

This discussion will focus solely on Phase 1 of an enterprise architecture initiative. This
phase should include the following:

* The Foundation (principles and objectives).

* The As-Is Architecture Model.

* The To-Be Architecture Model.

* The Transition Model (i.e., a road map).

If you take the time to fully develop each of those documents, you'll lay the groundwork
for discussing valuable opportunities for improvement.

The Foundation document should state your organization's definition of EA success. You
need to be specific here; avoid big words and esoteric ideas. Ask yourself what criteria
will be important when you're deciding how to balance IT-driven objectives with
companywide interests. You might end up with principles like these:

* We evaluate solutions based on scalability, extensibility, interoperability and

compatibility.

* We use off-the-shelf tools.

* We integrate enterprise security into all aspects of technology, from the physical to the
virtual.

Whatever they turn out to be, your principles should be reviewed with all members of the
IT team and the business team. They will be used to drive all future discussions and
decisions.

The Four Phases of EA

The first phase of an enterprise architecture project paves the way for the others.
1. The Foundation, the As-Is and To-Be Architecture Models, and the Transition Model.
This phase establishes the criteria used to guide decisions about IT, models the IT
architecture today, identifies where IT should be in three years and then describes how to
get there.

2. IT Vetting and Communication. This involves an in-depth review of IT projects and

the road map, as well as the plan for communicating with the business about the project.

3. Business Alignment and Governance. This phase contains a review of the business
needs and the development of the processes needed to support them. It is interactive with
the business.

4. Deployment, and Portfolio Metrics. The three-year road map is implemented, and
metrics are used to continually track, review and refine the programs.

-- Jennifer Pfaff

Once your Foundation is complete, you can move on to documenting both the As-Is and
To-Be Architecture Models. These documents should graphically represent the
organization's current and desired enterprise architectures. Remember, simple is better.
Try to keep each model to one page. If you're stumped, search the Internet for sample
frameworks and look for examples from parallel industries. Be patient; developing the
best model for your organization will require a few iterations.

In the beginning, there may be a learning curve as the IT team determines the appropriate
level of detail. There will be a temptation to list the hundreds (or thousands) of software
applications that your organization has, but it's the summarized information that is critical
to capture. Keep your EA team focused on developing a model -- the details can be filled
in as the team moves forward.

Your model could have a hierarchy like this:

* Enterprise (the complete environment).

* Domains (independent categories, like Infrastructure).

* Categories (logical subsets, like Network/Telecom).

* Elements (the most granular support functions, like Routers).

Once your team defines all the relevant technology domains for your business, the
elements can be prioritized according to the ROI for each element's improvement
opportunity. For example, the elements could be color-coded, with red drawing attention
to a high ROI opportunity, yellow for medium ROI and green for a low ROI element.
Don't be afraid to change the ranking of each element on the To-Be Model as new
information becomes available and corporate strategies change.
The Road Map

Finally, you'll need to explain how you plan to help the business get from the As-Is
Model to the To-Be Model. The best way to do that is to create a graphical road map.
This is the final deliverable in Phase 1, and it's a critical component that will help ease
senior management's angst about the path forward. This key transition moves the project
from an IT focus to a discussion about the business and improvement efforts.

The road map should include deadlines for achieving each part of the To-Be Model, and
it should show the organization's progress toward each goal. The road map should depict
the phased implementation of projects so business people can review the timeline. If
business executives don't agree with the timing in the road map, they can speak up and
make adjustments.

Using color coding, the road map can also demonstrate how the business changes
throughout the process; for example, along a three-year span, a project's priority may
change from green to red based on agreed-upon criteria.

The road map is a great asset that should be used to continually articulate the value of
your EA program to senior management.

These four deliverables will become catalysts for meaningful discussions with your
business counterparts using a common language. They'll provide the business with
insights for determining which IT projects to fund, based on the color-coded priorities.
And you'll have a road map showing how you're going to get from where you are to
where you want to be.
AGILE EA

When project teams work under the assumption that they can do anything that they want,
that they can use any technology that they want, chaos typically results. Functionality and
information will be duplicated and reuse will occur sporadically if at all. Systems will not
integrate well. Systems will conflict with one another and cause each other to fail. Costs
will skyrocket because similar products from different vendors, or even simply different
versions of the same product, will be purchased and then operated within production.
Although each individual project may be very successful, as a portfolio they may have
serious challenges. It doesn’t have to be this way.
The cold reality is that very few software-based systems exist in a vacuum, instead they
must co-exist with several and sometimes hundreds of other systems. Applications must
co-exist effectively with the other systems within your organization. Therefore an
application must minimally be developed so that it doesn’t cause adverse affects on your
other systems and ideally it should be built to take advantage of and to enhance a shared
infrastructure. Every system must be built so it can fit into your existing environment,
better yet so that it reflect s the future vision for your organization. This sort of
information should be captured in your enterprise architecture, in current state and future
state models respectively. One goal for agile enterprise architects is to ensure that this
happens in an effective manner, to ensure that the needs of the business stakeholders are
understood and anticipated, and to support project teams in their development efforts.

Why are enterprise issues an important aspect of the Agile Data (AD) method? Because
data is an enterprise asset. It isn’t your only enterprise asset, but it is an important one.
My philosophy is that to be effective as a developer you must consider enterprise issues,
which is why Agile Data’s 2nd philosophy “development teams must consider and act
appropriately regarding enterprise issues” exists. However, to remain agile your
organization must find a way to streamline their enterprise activities to support agile
software development teams in this endeavor. Hence Agile Data’s 3rd philosophy
“Enterprise groups exist to nurture enterprise assets and to support other groups, such as
development teams, within your organization. These enterprise groups should act in an
agile manner that reflects the expectations of their customers and the ways in which their
customers work.”

In this article, I discuss:

1. A few assumptions
2. What is enterprise architecture?
3. Why enterprise architecture?
4. Challenges with current approaches
5. An agile approach
o Focus on people, not technology or techniques
o Keep it simple
 o Work iteratively and incrementally
o Roll up your sleeves
o Build it before you talk about it
o Look at the whole picture
6. Introducing an agile approach to enterprise architecture
7. What should your enterprise architecture efforts produce?
8. Potential problems with the agile Enterprise architecture approach

1. A Few Assumptions

This article has been written with the following assumptions:

• You've read The Philosophies of Agile Data, The Vision of the Agile Data
Method, and The roles on Agile Data Projects
• You're familiar with the values, principles, and practices of Agile Modeling and
Agile Documentation
• Your organization wants to support agile software development teams, perhaps
following eXtreme Programming (XP) or the Agile Unified Process (AUP), with
enterprise architecture efforts
• You're willing to rethink your existing approach to enterprise architecture, if any.

2. What is Enterprise Architecture?

For our purposes, enterprise architecture consists of the various structures and processes
of an organization, including both technical structures and processes as well as
business/domain structures and processes. Following this definition, an enterprise
architecture model is a representation of those structures and processes. A good
enterprise architecture model will depict the organization both as it is today and as it is
envisioned in the future, and will map the various views representing the architecture to
one another. These views include both business-oriented perspectives as well as
technical perspectives. In many ways enterprise architecture models are a
communication bridge between senior business stakeholders and senior IT professionals.
Unfortunately, within the IT industry the terminology isn’t used in quite this way.
Sometimes we use the term “enterprise architecture” to refer to the group of people
responsible for modeling and then documenting the architecture. Other times we use the
term to denote the process of doing this work. More commonly we are referring to the
models, documents, and reusable items (components, frameworks, objects, and so on)
that reflect the actual architecture. Unless otherwise noted, this is the way that I will use
the term at this site.

In the Enterprise Unified Process (EUP) I point out how some organizations choose to
separate the business/domain side of EA from the technical side of it, something which is
reflected in the EUP's enterprise business modeling and enterprise architecture disciplines
respectively. If your organization chooses to think of the EA as encompassing both,
which I recommend, then your EA strategy encompasses the scope of those two EUP
disciplines.

3. Why Enterprise Architecture?

The benefits of enterprise architecture can be summed up using three words: better,
faster, cheaper. It is important to realize that the better, faster, cheaper (BFC) benefits
come at a price. You must be willing to invest in the underlying organizational and
cultural structures to support them. You need to recognize that these costs exist and
ensure that the BFC benefits you achieve outweigh them. Better yet, adopt Agile
Modeling’s principle Maximize Stakeholder ROI and strive for maximal benefit.

4. Challenges With Current Approaches

As a consultant I have the privilege of working in a wide range of organizations across

the world. The result is that I get to see and try many different approaches to software
development, including enterprise architecture efforts. Over the years I have observed a
common set of problems that organizations seem to experience. I have yet to see an
organization that experiences all of these problems, although I have seen some that
experience all but one or two. These common problems are:

1. There isn’t an enterprise architecture effort.

2. Skewed focus.
3. Project teams don’t know the enterprise architecture exists.
4. Project teams don’t follow the enterprise architecture.
5. Project teams don’t work with the enterprise architects.
6. Outdated architecture.
7. Narrowly focused architecture models.
8. Dysfunctional “charge back” schemes.
9. A “do all this extra work because it’s good for the company” attitude.
A common thread behind these problems is a focus on processes and tools over
individuals and interactions, the exact opposite of the Agile Alliance’s first value. If your
organization experiences one or more of these problems then you may want to consider
taking an agile approach to enterprise architecture.

5. An Agile Approach

The Agile Data Method's third philosophy is "Enterprise groups exist to nurture
enterprise assets and to support other groups, such as development teams, within your
organization. These enterprise groups should act in an agile manner that reflects the
expectations of their customers and the ways in which their customers work." Let's
explore what that actually means.

First and foremost, the values, principles, and practices of Agile Modeling (AM) should
help to guide your enterprise architecture modeling and documentation efforts. This is
just a good start though. My experience is that to be successful at enterprise architecture
you need to rethink your overall approach and address five fundamental issues. These
issues are connected in a synergistic manner; you must address all of them otherwise you
will put your effort at risk. These issues are:

1. Focus on people, not technology or techniques

2. Keep it simple
3. Work iteratively and incrementally
4. Roll up your sleeves
5. Look at the whole picture
6. Make enterprise architecture attractive to your customers

5.1 Focus on People, Not Technology

Fred Brooks (1995) wrote that “The quality of the people on a project, and their
organization and management, are much more important factors in success than are the
tools they use or the technical approaches they take.” The reality is that enterprise
architectures are developed, evolved, and followed by people. All of the arguments over
“which model is right”, “which notation is right”, and “which paradigm is right” are
meaningless if you don’t have a viable strategy for working together effectively. You
could create a perfect enterprise architecture model but it doesn’t matter if project teams
can’t or won’t take advantage of it.

Effective enterprise architects will work with their customers, very often application
developers and agile DBAs, in the most effective manner possible. Sometimes this will
be face-to-face drawing sketches with them at a whiteboard, sometimes they will work
with project teams via video conferencing, sometimes they will answer questions via
email, and sometimes they will publish models and documents. I highly suggest
following the AM practice Display Models Publicly for your architectural models and
documents – publish them online at an internal web site and even consider putting up
paper versions of critical diagrams in their workspaces. A common mistake that I’ve
seen architecture groups make is to put their diagrams on the walls within their work
areas but not the work areas of the application developers. Better yet, as I argue below
there shouldn’t be separate work areas to begin with.

Enterprise architects also work as “boundary spanners” between project teams and the
people within your organization that have the long-range vision – very often senior IT
and senior business executives.

An interesting observation is that enterprises have two organizational structures – the

formal one documented by your organization chart and the informal one that people use
to get things done. Within IT departments there are always the “go to guys” that
developers work with to get things done, very often other developers that have critical
skills or knowledge. Agile enterprise architects understand this and actively seek to
become “go to guys”.

5.2 Keep it Simple

A critical concept is that your enterprise architecture models and documents just need to
be good enough, they don’t need to be perfect. It is naïve to assume that you can produce
perfect artifacts, you’re only human: you will never get it perfectly right and nobody
expects you to anyway. Furthermore, even if you did manage to create perfect artifacts
they’d be out of date the day after you published them because something within your
business or technical environment would change (Embrace Change is also an AM
principle). Why is this important? My experience is that a hand-drawn sketch today on a
plain old whiteboard (POW) can often be far more valuable than a fully documented and
validated document several months from now. Timely guidance from an enterprise
architect who understands the current environment and the future vision for the
enterprise, even when this guidance is imperfect and based on incomplete information, is
often far better than the uneducated guesses that a project team will make on their own
while they wait for the official architecture to be published.

By keeping your enterprise architecture artifacts simple you increase the chances that
your audience will understand them, that project teams will actually read them, and that
you will be able to keep them up to date over time. Overly detailed documents might
look impressive sitting on a shelf, but a simple model that project teams actually use is
what your true goal should be. You might find When is Enough Modeling Enough? to be
interesting.

5.3 Work Iteratively and Incrementally

Agile enterprise architects work in an iterative and incremental manner. Agile modelers
will follow the practice Apply the Right Artifact(s) and use a wide variety of modeling
techniques as required (more on this later). They will also follow the practice Iterate To
Another Artifact when they realize that the model that they are working on either isn’t the
appropriate one with which to depict a concept or because they are simply stuck and need
to break out of their “analysis paralysis”. They will also follow the practice Create
Several Models In Parallel so that it is easy for them to iterate back and forth between
artifacts. Instead of holding a use case modeling session an agile modeler will focus on
requirements modeling, or even just modeling, and work on use cases, business rules,
change cases, and whatever other artifact they require to get the job done. The
advantage of these practices is that the right model is used for the task at hand.

Agile modelers will also follow the practice Model in Small Increments, modeling just
enough to fulfill the purpose at hand and then moving on to the next task. They don’t try
to create complete models, instead they create models that are just good enough. When
they find that their models are not sufficient they work on them some more. The
advantage of this approach is that they evolve their models incrementally over time,
effectively taking a just-in-time (JIT) model storming approach that enables them to get
the models in the hands of their customers as quickly as possible.

On the preceding advice, some readers may say to themselves “All of this sounds great,
particularly for a project team, but enterprise architecture is different. It’s more
complex. It’s more important. It requires significant modeling up front to get it right.”
Aaarrrrggghhh!!! That’s old-style thinking. Enterprise architects can work in an iterative
and incremental manner if they choose to.

Figure 1 overviews how to take an Agile Model Driven Development (AMDD) approach
to enterprise architecture. The enterprise architecture team would define the initial
architectural vision and models, a process that would likely take several days or even a
week or two. Any longer and you’d be at risk of developing architectural models that
don’t actually reflect something that would work in practice. Remember, your models
need to be just good enough, not perfect. The idea is that your enterprise model(s) start
out small and are fleshed out over time based on the feedback you receive from both the
business community and from project teams.

Figure 1. Agile Model Driven Development (AMDD) at the enterprise level.

5.4 Roll Up Your Sleeves

Although an important part of the job of an enterprise architect is modeling and

documentation, that should not be your primary focus. Supporting the architecture within
project teams should be, coaching developers in the architecture and architecture skills.
The best way to do this is to get involved with project teams, to work with them to
understand the enterprise architecture and to try it out in practice. In other words, the
enterprise architects will often take on the roles of "architecture owners" on the
application teams. This approach has several benefits:

• You quickly discover whether or not your ideas work, and if so then how well.
• You improve the chance that project teams understand the architecture because
you’re working with them face-to-face.
• You cross-fertilize ideas, particularly technical ones, across teams, quickly
sharing good ideas and strategies.
 • You improve the chance that a common infrastructure, both technical and
business, will be built and reused over time because the project teams will be
working towards the enterprise architecture.
• You gain experience in the tools and technologies that the project teams work
with, as well as the business domain itself, improving your own understanding of
what it is that you’re architecting.
• You obtain concrete feedback that you can then act on to improve the
architecture, enabling it to evolve over time to meet the actual needs of your
organization.
• You gain the respect of your primary customers, the application development
teams, because they see that you’re participating and not simply pontificating.
• You actively help to build software-based systems, the primary goal of IT
professionals.
• You can mentor the application developers and agile DBAs on the project teams
in modeling and architecture, improving their skill sets.
• You provide clear benefit to application teams because you’re helping them to
fulfill their immediate goals, forsaking the “do all this extra work because it’s
good for the company” attitude for a more attractive “let me help you achieve
your goals, and by doing so together we’ll do something good for the company”
attitude.
• You work closely with the development teams and enterprise administrators to
ensure that your overall data management (including Master-Data Management
(MDM)), security management, network management, ... efforts support and
enhance the development teams efforts instead of hinder them.

My experience is that the enterprise architects need to be active members of project

teams, and to do that they must be co-located with them. When architects are in a
different location, perhaps a different corner, on another floor, or even in another
building, their ability to communicate with and work together effectively with the project
team(s) they are trying to support is dramatically diminished. The implication is that
enterprise architects may need to become nomadic, moving between their “home base” to
the work areas of the project team(s) that they support. When you work side by side with
someone you pick up more information (often just by overhearing something) and you
make yourself easily available to them thus increasing the likelihood that they will take
advantage of your expertise.

5.5 Build It Before You Talk About It

Agile enterprise architects will ensure that their technical ideas actually work before they
advice project teams to try them by writing a small system to validate the idea. This is
called a spike solution in eXtreme Programming and a technical prototype or skeleton in
the Rational Unified Process (RUP). The idea is that you write just enough code to verify
that what you think will work actually does. This helps to reduce technical risk because
you’re making technology decisions based on known facts instead of good guesses.
5.6 Look at the Whole Picture

Agile enterprise architectures, agile modelers in general, believe in the principle Multiple
Models and thus strive to look at the whole picture. They don’t just focus on data
models, or object/component models, or business models, or whatever type of model
might tickle their fancy. Instead they strive to model from several points of view so that
their understanding and description of the architecture is more robust.

5.7 Make Your Enterprise Architecture Attractive to Your Customers

Agile enterprise architects realize that they need to make their work, including their
services, attractive to their customers (developers and business stakeholders). If your
customers perceive that you have value to add, that your enterprise architecture efforts
will aid them in their jobs, then they are much more likely to work with you. If, on the
other hand, they think that you’re wasting their time they won’t work with you. They’ll
find ways to avoid you, to cancel or postpone meetings with you, to find ways around
you.

6. Introducing an Agile Approach to Enterprise Architecture

Introducing the techniques and philosophies described in this article will prove difficult
in many organizations, particularly those that have an established enterprise architecture
group that follows a traditional approach. Adoption agile techniques requires a change in
mindset – agile enterprise architects are service oriented, realizing that it is their job to
help project teams to succeed and to work with senior stakeholders to define and evolve
the corporate vision. Agile enterprise architects realize that they need to make it as easy
as possible for other people to work with them and that they must provide perceived
value to the teams that they support. They realize these things, and act accordingly,
because they know that the people they are supposed to serve will ignore them if they
don’t. In the end it’s all about people and the way that you interact with them.

My experience is that the best way to introduce agile architecture techniques into an
organization is to start small at first and grow your strategy over time. This approach
allows you to gain some initial successes, to learn from your experiences (because
everything won’t go perfectly right), and to evolve your strategy based on those
learnings. A common mistake is to try to put an enterprise architecture team in place and
have all teams start to follow the new vision. The typical result is that existing project
teams become confused, the enterprise architecture team becomes swamped trying to
play catch up, and fighting ensues over “which is the best way”. The fundamental
mistake that is made with this approach is that it doesn’t allow the enterprise architects to
build a solid foundation from which to work, to build up the proof that their approach
actually works, and basically to get ahead of the project teams.

7. What Should Your Enterprise Efforts Produce?

If you’re hoping for an exact list of deliverables here then you need to go back and re-
read this article because you haven’t gotten it yet. Sorry for being harsh, but sometimes
you just need to say it as it is. However, it is important to define a set of goals that
should be achieved. In priority order, these goals are:

1. Customer support for the enterprise architecture.

2. A vision and plan to achieve that vision.
3. A collection of models and documentation describing the architecture.

8. Potential Problems With The Agile Enterprise Architecture Approach

No approach is perfect, including this one. I would be remiss if I didn’t identify these
known issues:

1. It does not include an explicit way to ensure compliancy (although having

enterprise architects embedded on the teams goes a long way towards this).
2. It depends on people being responsible.
3. It requires you to actively strive to keep things simple.
4. It requires you to accept an agile approach to modeling and documentation.

The approach described in this article works incredibly if you let it. Your most important
take away point is that it’s all about people. Fancy tools based on theoretically sound
frameworks, metamodels, or modeling languages are great to have but they won’t do
anything for you if developers don’t use them. It’s all about people. Sophisticated
models and documents are interesting to create, but they offer little value if nobody reads
them. It’s all about people.