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.

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 (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

information security and sizing. server. written reports on technologies. baseline (operations). reliability. enterprise test. labor and hardware costs across multiple IT Technical areas Review other application team or vendor architectures. logical. architecture resource needs. validating scope. 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. tool choice. performance. application integration and virtualization technologies. and engineering teams Create and document architecture artifacts when in the role of a project architect. flexibility. and promote them across the enterprise using the CTO and Enterprise Architecture channels. flexibility. scalability. reusability opportunities. Consult on production issues and driving root cause analysis and remediation. performance. database. with a focus on architectural standards. and physical architecture and design documents Responsible for growth. Build executive level presentations on architectural direction. 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. identifying risks with the application integration approach. 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. growth. reliability. Responsible for architecture of IT technical areas across application network. infrastructure. is seeking an experienced B2B Enterprise Architect for a key role with our Dallas-based consumer products client. Estimate software. Inc. scalability. directional. and total cost of ownership Responsible for infrastructure architecture deliverables including conceptual. options and solution cost benefit analysis .* 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. 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.

data marts. Ab Initio. and customer facing skills Experience with solution and application infrastructure including Windows and Linux. and Load (ETL) based solutions and ETL tools such as Informatica PowerCenter. application architects. development leads. leadership. and application and report development and data marts Solid technical aptitude. web servers. Storage Arrays. Virtualization. dashboards. 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. project architects. oral and written communication skills Past history of building relationships with a wide range of individuals including CTOs/CIOs. sizing. and firewalls Experience with Enterprise Application Integration (EAI) based solutions and EAI tools such as TIBCO EMS/BW Experience with Extract. 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. solution architects. VMWare. or large file transfer tools Experience with databases such as SQL Server. Experience with authentication. reporting. large data movement. third party software. implementation. or DB2 and data modeling Experience with capacity planning. middleware. networks. Oracle. 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 . and single sign on Solid understanding and experience in virtualization technologies for Windows and Unix platforms Understands application. load balancers.The ideal candidate will have the following skills/experience: • • • • • • • • • • • • • • • • • • • Experience with the design. authorization. security. project and program manager. application server. mentoring. and operation of B2B Gateways Experience with EDI and other B2B standards Experience in infrastructure. Transform. Storage) Strong analytical skills.

or enterprise architecture. business systems. information resources. software applications. together called "artifacts". drawings. they produce lists.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. for short. is considered by EA practitioners an 'enterprise' level architectural description. 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. These artifacts describe the logical organization of business functions. sufficiently complete to describe the enterprise in useful ways. computing capabilities. and continues The individual models in an EA are arranged in a logical manner that provides an everincreasing level of detail about the enterprise: its objectives and goals. information exchange and communications infrastructure within the enterprise.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 . business processes. documents and models. A collection of these artifacts. people organization. business capabilities. its processes and .

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".organisation. process models. This is the definition of enterprise architecture implicit in several EA frameworks including the popular TOGAF architectural framework. enterprise architects can ensure a holistic description is produced. An enterprise architecture framework collects together tools. artifact descriptions. 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. reference models and guidance used by architects in the production of enterprise-specific architectural description. "Information Systems Architecture" and "Technology Architecture" and then subdivides the information systems architecture into "Information Architecture and "Applications Architecture". The final level of Spewak's EAP is the "Implementation" or "Methods" level. See the related article on enterprise architecture frameworks for further information. The popular and most common four domains and their component parts look like this: 1. which deals with "how" to migrate the Enterprise to match the new model. techniques. corporate policies. By taking this approach. Operating Model .[9] The popular TOGAF framework divides the practice into three domains: "Business Architecture". "Applications Architecture" and "Technology 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. its systems and data. Business: 1. In 1992. Strategy maps. goals. 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". the technology used and any other relevant spheres of interest.[11] The dividing of the practice into a number of domains allows enterprise architects to describe an enterprise from a number of important perspectives.

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



Similarly.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. To manage this scale and complexity. and because enterprises can be large and complex. the models associated with the discipline also tend to be large and complex. 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. 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. 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. they may wish to specify .

S. safeguarded. 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. many frameworks such as DoDAF. organized. which in turn was derived from the IEEE model 1003. data models. state diagrams.the U. application developers.g. system providers. MODAF.g. For business view the planner and owner's level .[5] In recent years. As this benefit has emerged. systems architectures.[3] The TOGAF TRM was originally derived from the Technical Architecture Framework for Information Management (TAFIM). Applications based on these models can then query the underlying architectural information. This technical reference model wanted to use open systems and new technologies available in the commercial market. or AGATE have adopted a standard meta model which defines the critical architectural elements and the dependencies between them. The first draft of TAFIM was completed in 1991 with the TAFIM Technical Reference Model (TAFIM TRM). Enterprise Architecture started with the Zachman Framework in 1987. designer's view and developer's view in this order. including consumers. to develop a DoD-wide application. owner's view. The ownership can be divided into 4 broad categories: planner's view. All the views are mostly hierarchical in nature.) it is possible to trace the impact of organizational change on the systems. organizational charts. Department of Defense stipulates that specific DoDAF views be provided by equipment suppliers for capital project above a certain value. it has become apparent that a key benefit to be gained from Enterprise architecture is the ability to support decision making in changing businesses. and procurement agencies". Another early implementation of an Enterprise Architecture framework was the "Technical Architecture Framework for Information Management" (TAFIM).certain views be used in the documentation of procured systems .) and technical models (e. system integrators. etc. Because Enterprise Architecture brings together business models (e. etc. and also the business impact of changes to the systems.0[4] or POSIX Open System Environment: a standard "to construct an information processing system. process models. providing a simple and strong mechanism for tracing strategies to organizational and technological impacts. 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 application services are also referred in Serviceoriented architecture (SOA). The designer's view of business is also known as the analytical view and there are various standards for modeling this view. Enterprise Information Architect. Enterprises do have millions of instances of data entities.a U. The basic data model type which is most commonly used is called ERD (Entity Relationship Diagrams. For Example : Enterprise Business Architect. Enterprise Application Architect. 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. Information/Data.S. Many Enterprise Architecture Teams consist of Individuals with skills aligned with the Enterprise Architecture Domains and Sub Domain Disciplines.901-X. subject and entity forms a hierarchical view of data. The data view starts with the data classes which can be decomposed into data subjects which can be further decomposed into data entities.the Reference Model of Open Distributed Processing (ITU-T Rec. Application/Integration and Technical/Infrastructure).a four-nation effort to develop a common ontology for architecture interoperability RM-ODP . An Example of the EA Domain and Sub Domains is in the image on the right. see Entityrelationship model). These domains can be further divided into Sub domain disciplines. The Class. The Enterprise Architecture Reference Traditional Model offers clear distinction between the Architecture Domains (Business. The technical services are typically supported by software products. . Federal-funded guide to EA in the context of legislative and strategic business requirements. The capabilities are supported by the services. etc.904 | ISO/IEC 10746) defines an enterprise architecture framework for structuring the specifications of open distributed systems. 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) . Generalised Enterprise Reference Architecture and Methodology (GERAM) IDEAS Group . X. The designer's view typically represents the execution level which uses standards like Business Process Execution Language (BPEL). One mostly commonly used modeling standard is the Business Process Modeling Notation (BPMN).is typically called the value chains (which are descriptive by nature). Enterprise Infrastructure Architect.

the UK Ministry of Defence Architecture Framework NATO Architecture Framework AGATE .A Reference Architecture for Collaborative Networks .S.the DND/CF Architecture Framework (CAN) [edit] Government frameworks • • • Government Enterprise Architecture (GEA) . MEGAF is an infrastructure for realizing architecture frameworks that conform to the definition of architecture framework provided in the ISO/IEC 42010 standard.the France DGA Architecture Framework DNDAF .a common framework legislated for use by departments of the Queensland Government FDIC Enterprise Architecture Framework Federal Enterprise Architecture Framework (FEAF) .conceived by Roger Evernden in 1996 Zachman Framework .a framework produced by the Office of Management and Budget for use within the U. [12] Integrated Architecture Framework (IAF) . based on the work of John Zachman at IBM in the 1980s The Enterprise Framework . [edit] Commercial frameworks • • • • • • • Solution Architecting Mechanism (SAM) .Atos Origin's Enterprise Architecture Framework OBASHI . results and best-practices gathered through real-life implementations of various building blocks that altogether provide a realizable architecture and working solutions.from Capgemini company in 1993 CLEAR Framework for Enterprise Architecture .a methodology based on architecture architecture framework.the OBASHI Business & IT methodology and framework Information FrameWork (IFW) . Good enough architecture methodology .not focused on a single enterprise but rather on networks of enterprises [10] [11] [edit] Open Source Frameworks • • TRAK . ARCON .• • • TOGAF . developed by Sam Holcman at the Enterprise Architecture Center of Excellence ([1]) [edit] Defense industry frameworks • • • • • DoDAF .a general systems-oriented framework based on MODAF 1.the Open Group Architecture Framework .a widely used framework including an Architectural Development Method and standards for describing various types of architecture.the US Department of Defense Architecture Framework MODAF .2 and released under GPL/GFDL.A coherent architecture framework consisting of a set of integral modules. Government .

a reference framework from the Dutch Government E-overheid NORA UML Modeling Features • • • • Latest UML 2.3 specification XMI 2.a framework for treasury.• • • NIST Enterprise Architecture Model Treasury Enterprise Architecture Framework (TEAF) .[13] Nederlandse Overheid Referentie Architectuur (NORA) .1 import and export Reporting in HTML and RTF MDA transformations . published by the US Department of the Treasury in July 2000.

• • • • • • • • • • • • • Profiles and Technology support Testing. resource tracking. maintenance Reverse engineer source code in 10+ languages Import database schema Visualize XSD and WSDL source Import .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 . 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.NET and Java binaries From single users to large teams Repository support for major DBMSs Fast to load.

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. in different combinations and for different constituencies. They also should have broad knowledge of technology capabilities. Ericksen adds.” says John Ericksen. Cherukuri says. 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. “It’s a unique personality—negotiation skills as well as technical skills. as a discipline. Furthermore. says Srini Cherukuri. the gaps that are identified represent opportunities for future IT investments. You need people who understand business and customer needs. That ability to persuade others to change is critical. though not necessarily code and query languages.. 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. he adds.. Computerworld — A successful enterprise architecture project can help unlock an IT department's true value to the business it supports. Companies usually look for IT professionals with 10 to 15 years of experience in order to find that combination of characteristics. senior director of IT operations. . “They're hard to find. With that understanding. he says.” Matson Navigation established an enterprise architecture group in 2004. chief operating officer and leader of technology and corporate services with PNC Financial Services Group (PNC). EA.• • 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. 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. Some companies even want their architects to have a master’s or doctorate degree in computer science or engineering.

* We use off-the-shelf tools. They will be used to drive all future discussions and decisions. If you take the time to fully develop each of those documents. if the business people have a chance to offer input. your principles should be reviewed with all members of the IT team and the business team. You need to be specific here. avoid big words and esoteric ideas. have your team step back and simplify. * The To-Be Architecture Model. a road map).. The Four Phases of EA The first phase of an enterprise architecture project paves the way for the others.e. but getting there isn't as difficult as you might think. * The As-Is Architecture Model. . The Foundation document should state your organization's definition of EA success. focused manager can jump-start an EA program by creating small deliverables that the business stakeholders can understand. Whatever they turn out to be. * We integrate enterprise security into all aspects of technology. Developing a good enterprise architecture program shouldn't require a dedicated full-time staff of specialists. you'll lay the groundwork for discussing valuable opportunities for improvement.Sound like a lofty endeavor? It is. A team led by a strong. interoperability and compatibility. Ask yourself what criteria will be important when you're deciding how to balance IT-driven objectives with companywide interests. (Hint: If your program's objectives can't be described in an elevator speech. You might end up with principles like these: * We evaluate solutions based on scalability.) Work with representatives from the business side to set up four easily understood documents. This discussion will focus solely on Phase 1 of an enterprise architecture initiative. they should be able to understand the business value of each phase of your EA program. from the physical to the virtual. extensibility. * The Transition Model (i. This phase should include the following: * The Foundation (principles and objectives).

like Routers). 4. If you're stumped. It is interactive with the business. like Network/Telecom). The three-year road map is implemented. simple is better. * Elements (the most granular support functions. This phase establishes the criteria used to guide decisions about IT. For example. Remember. Be patient. the elements can be prioritized according to the ROI for each element's improvement opportunity. search the Internet for sample frameworks and look for examples from parallel industries. This involves an in-depth review of IT projects and the road map. yellow for medium ROI and green for a low ROI element. In the beginning. Once your team defines all the relevant technology domains for your business. Your model could have a hierarchy like this: * Enterprise (the complete environment).Jennifer Pfaff Once your Foundation is complete. and the Transition Model. with red drawing attention to a high ROI opportunity. Business Alignment and Governance. * Domains (independent categories. IT Vetting and Communication. Try to keep each model to one page.1. Deployment. and metrics are used to continually track. The Foundation. the elements could be color-coded.the details can be filled in as the team moves forward. models the IT architecture today. and Portfolio Metrics. developing the best model for your organization will require a few iterations. Keep your EA team focused on developing a model -. identifies where IT should be in three years and then describes how to get there. there may be a learning curve as the IT team determines the appropriate level of detail. * Categories (logical subsets. you can move on to documenting both the As-Is and To-Be Architecture Models. 3. the As-Is and To-Be Architecture Models. as well as the plan for communicating with the business about the project. but it's the summarized information that is critical to capture. These documents should graphically represent the organization's current and desired enterprise architectures. review and refine the programs. . This phase contains a review of the business needs and the development of the processes needed to support them. There will be a temptation to list the hundreds (or thousands) of software applications that your organization has. -. 2. 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. like Infrastructure).

The Road Map Finally. the road map can also demonstrate how the business changes throughout the process. And you'll have a road map showing how you're going to get from where you are to where you want to be. If business executives don't agree with the timing in the road map. based on the color-coded priorities. This is the final deliverable in Phase 1. This key transition moves the project from an IT focus to a discussion about the business and improvement efforts. The best way to do that is to create a graphical road map. and it should show the organization's progress toward each goal. for example. They'll provide the business with insights for determining which IT projects to fund. . The road map should depict the phased implementation of projects so business people can review the timeline. The road map should include deadlines for achieving each part of the To-Be Model. you'll need to explain how you plan to help the business get from the As-Is Model to the To-Be Model. Using color coding. 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. along a three-year span. they can speak up and make adjustments. and it's a critical component that will help ease senior management's angst about the path forward. These four deliverables will become catalysts for meaningful discussions with your business counterparts using a common language.


will be purchased and then operated within production. not technology or techniques o Keep it simple . better yet so that it reflect s the future vision for your organization. and to support project teams in their development efforts. It doesn’t have to be this way. These enterprise groups should act in an agile manner that reflects the expectations of their customers and the ways in which their customers work. A few assumptions What is enterprise architecture? Why enterprise architecture? Challenges with current approaches An agile approach o Focus on people. instead they must co-exist with several and sometimes hundreds of other systems. This sort of information should be captured in your enterprise architecture. Hence Agile Data’s 3rd philosophy “Enterprise groups exist to nurture enterprise assets and to support other groups. Applications must co-exist effectively with the other systems within your organization. 5. Although each individual project may be very successful. However. One goal for agile enterprise architects is to ensure that this happens in an effective manner. My philosophy is that to be effective as a developer you must consider enterprise issues. within your organization.AGILE EA When project teams work under the assumption that they can do anything that they want. Systems will conflict with one another and cause each other to fail. 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. in current state and future state models respectively. to remain agile your organization must find a way to streamline their enterprise activities to support agile software development teams in this endeavor. that they can use any technology that they want. 3. or even simply different versions of the same product. Why are enterprise issues an important aspect of the Agile Data (AD) method? Because data is an enterprise asset. 2. Costs will skyrocket because similar products from different vendors. It isn’t your only enterprise asset. The cold reality is that very few software-based systems exist in a vacuum. Systems will not integrate well. but it is an important one. Functionality and information will be duplicated and reuse will occur sporadically if at all. which is why Agile Data’s 2nd philosophy “development teams must consider and act appropriately regarding enterprise issues” exists. 4. to ensure that the needs of the business stakeholders are understood and anticipated. such as development teams. I discuss: 1. chaos typically results. as a portfolio they may have serious challenges.” In this article.

and practices of Agile Modeling and Agile Documentation Your organization wants to support agile software development teams. . These views include both business-oriented perspectives as well as technical perspectives. Following this definition. A Few Assumptions This article has been written with the following assumptions: • • • • You've read The Philosophies of Agile Data. In many ways enterprise architecture models are a communication bridge between senior business stakeholders and senior IT professionals. an enterprise architecture model is a representation of those structures and processes. including both technical structures and processes as well as business/domain 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. Potential problems with the agile Enterprise architecture approach o o o o 1. What should your enterprise architecture efforts produce? 8. if any. with enterprise architecture efforts You're willing to rethink your existing approach to enterprise architecture. perhaps following eXtreme Programming (XP) or the Agile Unified Process (AUP). 2.Work iteratively and incrementally Roll up your sleeves Build it before you talk about it Look at the whole picture 6. and The roles on Agile Data Projects You're familiar with the values. principles. enterprise architecture consists of the various structures and processes of an organization. What is Enterprise Architecture? For our purposes. The Vision of the Agile Data Method. and will map the various views representing the architecture to one another. Introducing an agile approach to enterprise architecture 7.

7. 2. faster. which I recommend. 6. adopt Agile Modeling’s principle Maximize Stakeholder ROI and strive for maximal benefit. and so on) that reflect the actual architecture. Over the years I have observed a common set of problems that organizations seem to experience. 3. and reusable items (components. You must be willing to invest in the underlying organizational and cultural structures to support them. Sometimes we use the term “enterprise architecture” to refer to the group of people responsible for modeling and then documenting the architecture. including enterprise architecture efforts.Unfortunately. More commonly we are referring to the models. cheaper. These common problems are: 1. Skewed focus. Dysfunctional “charge back” schemes. Why Enterprise Architecture? The benefits of enterprise architecture can be summed up using three words: better. Unless otherwise noted. You need to recognize that these costs exist and ensure that the BFC benefits you achieve outweigh them. I have yet to see an organization that experiences all of these problems. Project teams don’t work with the enterprise architects. A “do all this extra work because it’s good for the company” attitude. 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. 3. this is the way that I will use the term at this site. Challenges With Current Approaches As a consultant I have the privilege of working in a wide range of organizations across the world. frameworks. It is important to realize that the better. 4. . within the IT industry the terminology isn’t used in quite this way. cheaper (BFC) benefits come at a price. Narrowly focused architecture models. Better yet. something which is reflected in the EUP's enterprise business modeling and enterprise architecture disciplines respectively. faster. If your organization chooses to think of the EA as encompassing both. The result is that I get to see and try many different approaches to software development. then your EA strategy encompasses the scope of those two EUP disciplines. Project teams don’t know the enterprise architecture exists. There isn’t an enterprise architecture effort. 4. although I have seen some that experience all but one or two. objects. 8. 9. Project teams don’t follow the enterprise architecture. Outdated architecture. Other times we use the term to denote the process of doing this work. 5. documents.

4. are much more important factors in success than are the tools they use or the technical approaches they take. the exact opposite of the Agile Alliance’s first value. Effective enterprise architects will work with their customers. All of the arguments over “which model is right”. Sometimes this will be face-to-face drawing sketches with them at a whiteboard. 3." Let's explore what that actually means. These enterprise groups should act in an agile manner that reflects the expectations of their customers and the ways in which their customers work. 5. If your organization experiences one or more of these problems then you may want to consider taking an agile approach to enterprise architecture. This is just a good start though. sometimes they will work with project teams via video conferencing. Not Technology Fred Brooks (1995) wrote that “The quality of the people on a project. These issues are: 1. and their organization and management. First and foremost. An Agile Approach The Agile Data Method's third philosophy is "Enterprise groups exist to nurture enterprise assets and to support other groups. These issues are connected in a synergistic manner. within your organization.1 Focus on People.A common thread behind these problems is a focus on processes and tools over individuals and interactions. in the most effective manner possible. such as development teams. 5. the values.” The reality is that enterprise architectures are developed. sometimes they will answer questions via . 2. My experience is that to be successful at enterprise architecture you need to rethink your overall approach and address five fundamental issues. and “which paradigm is right” are meaningless if you don’t have a viable strategy for working together effectively. not technology or techniques Keep it simple Work iteratively and incrementally Roll up your sleeves Look at the whole picture Make enterprise architecture attractive to your customers 5. you must address all of them otherwise you will put your effort at risk. principles. “which notation is right”. very often application developers and agile DBAs. and practices of Agile Modeling (AM) should help to guide your enterprise architecture modeling and documentation efforts. 6. evolved. Focus on people. and followed by people. 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.

very often other developers that have critical skills or knowledge. By keeping your enterprise architecture artifacts simple you increase the chances that your audience will understand them. Furthermore. Overly detailed documents might look impressive sitting on a shelf. Timely guidance from an enterprise architect who understands the current environment and the future vision for the enterprise. they don’t need to be perfect. 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. even when this guidance is imperfect and based on incomplete information. you’re only human: you will never get it perfectly right and nobody expects you to anyway. 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). Agile enterprise architects understand this and actively seek to become “go to guys”. 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 Keep it Simple A critical concept is that your enterprise architecture models and documents just need to be good enough. 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. that project teams will actually read them. 5. 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. and sometimes they will publish models and documents. 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. but a simple model that project teams actually use is what your true goal should be. 5. Better yet. Within IT departments there are always the “go to guys” that developers work with to get things done. It is naïve to assume that you can produce perfect artifacts. and that you will be able to keep them up to date over time. 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.3 Work Iteratively and Incrementally . as I argue below there shouldn’t be separate work areas to begin with. You might find When is Enough Modeling Enough? to be interesting.

Agile enterprise architects work in an iterative and incremental manner. 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. instead they create models that are just good enough. The advantage of these practices is that the right model is used for the task at hand. not perfect. change cases. 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. . Agile Model Driven Development (AMDD) at the enterprise level. or even just modeling. They don’t try to create complete models. Agile modelers will also follow the practice Model in Small Increments. Any longer and you’d be at risk of developing architectural models that don’t actually reflect something that would work in practice. On the preceding advice. Enterprise architects can work in an iterative and incremental manner if they choose to. It requires significant modeling up front to get it right. 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. It’s more complex. your models need to be just good enough. business rules. and work on use cases. 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). but enterprise architecture is different. 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”. Remember. When they find that their models are not sufficient they work on them some more. modeling just enough to fulfill the purpose at hand and then moving on to the next task. It’s more important. 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. Instead of holding a use case modeling session an agile modeler will focus on requirements modeling. Figure 1 overviews how to take an Agile Model Driven Development (AMDD) approach to enterprise architecture. some readers may say to themselves “All of this sounds great.” Aaarrrrggghhh!!! That’s old-style thinking. The advantage of this approach is that they evolve their models incrementally over time. Figure 1. particularly for a project team. and whatever other artifact they require to get the job done.

5. the enterprise architects will often take on the roles of "architecture owners" on the application teams. In other words. You improve the chance that project teams understand the architecture because you’re working with them face-to-face. coaching developers in the architecture and architecture skills. You cross-fertilize ideas. across teams. and if so then how well. quickly sharing good ideas and strategies. . particularly technical ones. to work with them to understand the enterprise architecture and to try it out in practice. This approach has several benefits: • • • You quickly discover whether or not your ideas work. The best way to do this is to get involved with project teams. that should not be your primary focus. Supporting the architecture within project teams should be.4 Roll Up Your Sleeves Although an important part of the job of an enterprise architect is modeling and documentation.

. You work closely with the development teams and enterprise administrators to ensure that your overall data management (including Master-Data Management (MDM)). . the application development teams. The idea is that you write just enough code to verify that what you think will work actually does. as well as the business domain itself. on another floor. 5. When architects are in a different location. and by doing so together we’ll do something good for the company” attitude. You actively help to build software-based systems. You gain the respect of your primary customers.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.. You gain experience in the tools and technologies that the project teams work with. their ability to communicate with and work together effectively with the project team(s) they are trying to support is dramatically diminished. 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. efforts support and enhance the development teams efforts instead of hinder them. network management. The implication is that enterprise architects may need to become nomadic. improving their skill sets. You obtain concrete feedback that you can then act on to improve the architecture. both technical and business. or even in another building. moving between their “home base” to the work areas of the project team(s) that they support. My experience is that the enterprise architects need to be active members of project teams. perhaps a different corner. This is called a spike solution in eXtreme Programming and a technical prototype or skeleton in the Rational Unified Process (RUP). the primary goal of IT professionals.• • • • • • • • You improve the chance that a common infrastructure. and to do that they must be co-located with them. This helps to reduce technical risk because you’re making technology decisions based on known facts instead of good guesses. 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. improving your own understanding of what it is that you’re architecting. You can mentor the application developers and agile DBAs on the project teams in modeling and architecture. enabling it to evolve over time to meet the actual needs of your organization. will be built and reused over time because the project teams will be working towards the enterprise architecture. because they see that you’re participating and not simply pontificating. security management. You provide clear benefit to application teams because you’re helping them to fulfill their immediate goals..

6 Look at the Whole Picture Agile enterprise architectures. 6. to cancel or postpone meetings with you. In the end it’s all about people and the way that you interact with them. that your enterprise architecture efforts will aid them in their jobs. and act accordingly. Instead they strive to model from several points of view so that their understanding and description of the architecture is more robust. or whatever type of model might tickle their fancy. The fundamental mistake that is made with this approach is that it doesn’t allow the enterprise architects to . particularly those that have an established enterprise architecture group that follows a traditional approach. and fighting ensues over “which is the best way”. This approach allows you to gain some initial successes. to learn from your experiences (because everything won’t go perfectly right). believe in the principle Multiple Models and thus strive to look at the whole picture. the enterprise architecture team becomes swamped trying to play catch up. 5. attractive to their customers (developers and business stakeholders). then they are much more likely to work with you. 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 don’t just focus on data models. agile modelers in general.5. If. Adoption agile techniques requires a change in mindset – agile enterprise architects are service oriented. A common mistake is to try to put an enterprise architecture team in place and have all teams start to follow the new vision. or object/component models. because they know that the people they are supposed to serve will ignore them if they don’t. The typical result is that existing project teams become confused. 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. on the other hand. to find ways around you. or business models. including their services. They’ll find ways to avoid you. Introducing an Agile Approach to Enterprise Architecture Introducing the techniques and philosophies described in this article will prove difficult in many organizations. 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.7 Make Your Enterprise Architecture Attractive to Your Customers Agile enterprise architects realize that they need to make their work. They realize these things. and to evolve your strategy based on those learnings. they think that you’re wasting their time they won’t work with you. If your customers perceive that you have value to add.

What Should Your Enterprise Efforts Produce? If you’re hoping for an exact list of deliverables here then you need to go back and reread this article because you haven’t gotten it yet. but sometimes you just need to say it as it is. it is important to define a set of goals that should be achieved. A vision and plan to achieve that vision. 3. A collection of models and documentation describing the a solid foundation from which to work. 7. these goals are: 1. It requires you to accept an agile approach to modeling and documentation. Sophisticated models and documents are interesting to create. Your most important take away point is that it’s all about people. 3. In priority order. It depends on people being responsible. 8. including this one. It requires you to actively strive to keep things simple. to build up the proof that their approach actually works. but they offer little value if nobody reads them. Customer support for the enterprise architecture. 4. I would be remiss if I didn’t identify these known issues: 1. The approach described in this article works incredibly if you let it. or modeling languages are great to have but they won’t do anything for you if developers don’t use them. . Fancy tools based on theoretically sound frameworks. 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’s all about people. metamodels. 2. Sorry for being harsh. It’s all about people. However. and basically to get ahead of the project teams. Potential Problems With The Agile Enterprise Architecture Approach No approach is perfect.

Sign up to vote on this title
UsefulNot useful