Job descriptionmapping 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 timing5. Suppliers of hardware, software, and services

2. Information: 1. Information architecture - a holistic view on the flow of information in an

enterprise2. Metadata - data that describes your enterprise data elements3. Data models : conceptual expressed as enterprise information architectures,

logical, and physical3. 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 flows4. 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 diagrams5. Intranet , Extranet, Internet, eCommerce, EDI links with parties within and

outside of the organization6. Operating System 7. Infrastructure software: Application servers, DBMS8. 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 todaywhite 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.