Mszifa96 01
•Download as PPT, PDF•
0 likes•94 views
Zachman Institute for Framework Advancement presentation 1996
Recommended
Recommended
More Related Content
Similar to Mszifa96 01
Similar to Mszifa96 01 (20)
More from Brian K. Seitz
More from Brian K. Seitz (8)
Recently uploaded
Recently uploaded (20)
Mszifa96 01
- 1. Enterprise ArchitectureEnterprise Architecture Theory and PracticeTheory and Practice Introducing the Architect’s paradigmIntroducing the Architect’s paradigm into Microsoftinto Microsoft Brian K. Seitz - Sr. Technologist WWITBrian K. Seitz - Sr. Technologist WWIT Ian Chang - Sr. Technologist WWITIan Chang - Sr. Technologist WWIT ZIFAZIFA © 1996© 1996 ™
- 2. IntroductionIntroduction Enterprise ArchitectureEnterprise Architecture The rational design of an Enterprise has been the hopeThe rational design of an Enterprise has been the hope and dream of CEOs, CIOs, Entrepreneurs, and managersand dream of CEOs, CIOs, Entrepreneurs, and managers since the advent of Frederick Taylor’s introduction ofsince the advent of Frederick Taylor’s introduction of Scientific Management. However, it was not untilScientific Management. However, it was not until recently were there sufficient tools to adequately describerecently were there sufficient tools to adequately describe and specify the richness that is Enterprise. Thisand specify the richness that is Enterprise. This presentation will provide just a brief insight to thepresentation will provide just a brief insight to the research being conducted in this area.research being conducted in this area.
- 3. AgendaAgenda Architect’s Paradigm examinedArchitect’s Paradigm examined Enterprise ArchitectureEnterprise Architecture Microsoft experienceMicrosoft experience Conclusions and Lessons learnedConclusions and Lessons learned QuestionsQuestions
- 4. Architect’s Paradigm examinedArchitect’s Paradigm examined What is the purpose of Architecture ?What is the purpose of Architecture ? What is Architecture ?What is Architecture ? Architectural ScopeArchitectural Scope Architectural TheoryArchitectural Theory Architecture is a riddle, wrapped in an engima, hidden in a mystery...
- 5. Architecture’s PurposeArchitecture’s Purpose is the management of complexityis the management of complexity This is accomplished through: Reduction Organization
- 6. What is Architecture ?What is Architecture ? A set of rules that determine choice, the usage, and organization of elements to create a “Built Environment” Examples of these elements in Dwelling Architecture are: Space, Light and Texture Function Componentry
- 7. Drawings areDrawings are notnot ArchitectureArchitecture Architecture is expressed through architectonics Commonly called design Drawings represent the intentions ( plans ) of the design process. Commonly called “a design” Blueprints are one form of drawing Seitz’s Maxium -For differentiating Architecture and Design: If you can impliment more than one way, you are likely to have an Architecture. Corollary: If you can impliment in only one way, you have a Design.
- 8. Drawings are Design representationsDrawings are Design representations Drawings manage design complexity through reduction.
- 9. Built Environments require a family of drawingsBuilt Environments require a family of drawings
- 10. Dwelling Architectural ScopeDwelling Architectural Scope Scale Time Product and Graphic Designers/ Artists Weeks Months Year s Decades Regions Days EarthCitiesLandscapesStructuresInteriorProducts Generation Centuries Interior Designer Architects Landscape Architects Urban Planners Regional Planners Global Planners Span Granularity
- 12. Architectural FrameworkArchitectural Framework Research Methods Theory and models of the environment, people, and their interactions Decision Theory Decision Theory The Behavioral Sciences Substantive Procedural Positive Designer’s WorldView Architectural Theory Professed substantive Professed procedural Normative Practice Building design Praxis content Building performance
- 13. Architectural ProcessArchitectural Process Design Activity (Praxis)Client Architecture Theory Architectural Style Design Theory Design Instance Product
- 14. Design PraxisDesign Praxis BrianK.Seitz1996 Activity Start Definition Analysis Synthesis Development Implementation (Owner) (Finance) Architect Contractor (Architect) Owner User (Architect) Owner Manufacturer Contractor (Architect) Contractor Manufacturer Subcontractor (Contractor) Subcontractor Manufacturer Architect (Contractor) Subcontractor Manufacturer Architect (Labor) Contractor Subcontractor Manufacturer(KeyRole) Team Phase Source: Swinburne(1969via JonLang1987 Market Finalize Constructive Directive Role Shift Professional Management Finalize Construction Cost TimeSchedule Economic Management Recycle&Modify Balance:Scope*Dollars*Time Re-examineGoalDefinition Operation Need Cost Time Resources Role Shift Goals Limits Define Facility Objective Research& Investigate Operation s Program Spatial Program Human Program Environmental Program Think Determine Group Dynamics Determine Adjacency Finalize Design Concept Aesthetic Position Other Disciplines Write Design Directive Establish Performance Critieria Investigate Alternatives Subsystem Interlock Simulation Location Logistics (Owner) Architect User Maintainer Critic (Owner) Architect Contractor Subcontractor Manufacturer Verify Operating Costs Maintain & Operate Interior Environmental Comfort Perform Functions Exterior Environmental Reinforcement Construction Management Construction Logistics Labor (On-site) (Off-site) Construct &Equip Facility Role Shift Review Performance Criteria Judge Nonquantifiables Measure Quantifiables Establish Performance Profile Stop Evaluation
- 15. An Example of Design PraxisAn Example of Design Praxis
- 19. Completed Floor planCompleted Floor plan
- 21. Theory and models of the environment, people, and their interactions Decision Theory Decision Theory The Behavioral Sciences Research Methods Building design Praxis content Building performance Practice Professed substantive Professed procedural Normative Substantive Procedural Positive Designer’s WorldView Who What Where When Why How Zachman ISA Owner Architect Contractor Manufacturer SubContractor Architectural Theory BrianK.Seitz1996 Activity Start Definition Analysis Synthesis Development Implementation (Owner) (Finance) Architect Contractor (Architect) Owner User (Architect) Owner Manufacturer Contractor (Architect) Contractor Manufacturer Subcontractor (Contractor) Subcontractor Manufacturer Architect (Contractor) Subcontractor Manufacturer Architect (Labor) Contractor Subcontractor Manufacturer (KeyRole) Team Phase Source: Swinburne(1969via Jon Lang 1987 Market Finalize Constructive Directive Role Shift Professional Management Finalize Construction Cost TimeSchedule Economic Management Recycle& Modify Balance:Scope *Dollars* Time Re-examineGoalDefinition Operation Need Cost Time Resources Role Shift Goals Limits Define Facility Objective Research& Investigate Operation s Program Spatial Program Human Program Environmental Program Think Determine Group Dynamics Determine Adjacency Finalize Design Concept Aesthetic Position Other Disciplines Write Design Directive Establish Performance Critieria Investigate Alternatives Subsystem Interlock Simulation Location Logistics (Owner) Architect User Maintainer Critic (Owner) Architect Contractor Subcontractor Manufacturer Verify Operating Costs Maintain & Operate Interior Environmental Comfort Perform Functions Exterior Environmental Reinforcement Construction Management Construction Logistics Labor (On-site) (Off-site) Construct &Equip Facility Role Shift Review Performance Criteria Judge Nonquantifiables Measure Quantifiables Establish Performance Profile Stop Evaluation
- 22. The EnterpriseThe Enterprise SalesSales ManufacturingManufacturing DealerDealer AccountingAccounting Executive ManagementExecutive Management Customer SupportCustomer Support CustomerCustomer Is manifested as an organizational entity (an entireIs manifested as an organizational entity (an entire corporation, division, branch or department) havingcorporation, division, branch or department) having a business mission - that generates a need to sharea business mission - that generates a need to share information.information. It is an association of resouces, ( fiscal,It is an association of resouces, ( fiscal, human, technological and intellectual), for thehuman, technological and intellectual), for the purpose of commerce.purpose of commerce.
- 23. BusinessBusiness ArchitectureArchitecture ApplicationApplication ArchitectureArchitecture TechnologyTechnology ArchitectureArchitecture Microsoft Solutions Framework InformationInformation ArchitectureArchitecture What is Enterprise Architecture ?What is Enterprise Architecture ? Describes the structure and dynamics ofDescribes the structure and dynamics of an Enterprisean Enterprise Encapsulates the rules of selecting andEncapsulates the rules of selecting and organizing components into a purposefulorganizing components into a purposeful whole.whole. Is multi-dimensional like DwellingIs multi-dimensional like Dwelling ArchitectureArchitecture
- 24. Today’s Distributed Application ArchitecturesToday’s Distributed Application Architectures SuppliersSuppliers DistributorsDistributors EnterpriseEnterprise MISMIS CustomerCustomer ss Users andUsers and Organization UnitsOrganization Units Network and GatewaysNetwork and Gateways Desktop Tools and InterfacesDesktop Tools and Interfaces Network Servers, Mainframes, Data Feeds, ..Network Servers, Mainframes, Data Feeds, ....
- 25. Products & TechnologiesProducts & Technologies CustomerCustomer ss SuppliersSuppliers DistributorsDistributors CorporateCorporate MISMIS Users andUsers and Business UnitsBusiness Units Windows NTWindows NT ServerServer ExchangeExchange & MAPI& MAPI SQL ServerSQL Server & ODBC& ODBC BackofficeBackoffice & OLE& OLE AccessAccess && SQL ServerSQL Server OfficeOffice && VisualVisual ToolsTools Windows NTWindows NT Server &Server & NetWareNetWare ServicesServices Windows 95Windows 95 && Windows NTWindows NT WorkstationWorkstation SNA Server, Mail gatewaysSNA Server, Mail gateways
- 26. Enterprise Architecture ScopeEnterprise Architecture Scope Time A larger problem domain ... Domain Scale Time Program DesignersWeeks Months Year s Decades Inter- Enterprise Days Industry/ Global EnterpriseBusiness Functions Business Processes ApplicationsTasks Generation Centuries Application Architect Business Systems Architects TBD Enterprise Architects TBD Global Planners Span Granularity
- 27. At Microsoft…..At Microsoft….. Introduction of a PraxisIntroduction of a Praxis Organizational redesignOrganizational redesign
- 28. Introducing an ArchitecturalIntroducing an Architectural PraxisPraxis BuildingBuilding ManagingManaging PlanningPlanning MSF Program ManagementProgram Management DevelopmentDevelopment TestingTesting User EducationUser Education LogisticsLogisticsProductProduct ManagementManagement Communication
- 29. Enterprise Planning PerspectivesEnterprise Planning Perspectives ……are only part of the solutionare only part of the solution Technology Architecture Business Architecture Application Architecture Information Architecture
- 30. The Essentials…The Essentials… • Architects - Team Model • A Framework • A Set of Plans • A Process Model
- 31. SalesSales Mfg.Mfg. Adm.Adm. FinanceFinance ITIT OrderOrder FulfillmentFulfillment BusinesBusines ss ProcessProcess Gain Leverage for the Enterprise CoordinatedCoordinated Enterprise/Enterprise/ TechnicalTechnical ArchitectureArchitecture and Plansand Plans ArchitectsArchitects PartnershipsPartnerships
- 32. The ArchitectThe Architect Capabilities and SkillsCapabilities and Skills Identifies and reports poor alignment between the business and technology goals Assures the “To-Be” Architecture aligns with business goals Designs an infrastructure to support the business solutions Has business and technical expertise and can influence key decision-makers Understands the technology, information, and application needs of the enterprise Owns the architectural processes Evangelizes the enterprise business and technology objectives
- 33. MSF Team ModelMSF Team Model DevelopmentDevelopment TestingTesting User EducationUser Education LogisticsLogisticsProductProduct ManagementManagement ProgramProgram ManagementManagement
- 34. Program ManagementProgram Management DevelopmentDevelopment TestingTesting User EducationUser Education LogisticsLogistics DevelopmentDevelopment TestingTesting User EducationUser Education LogisticsLogisticsProductProduct ManagementManagement The Architect Role AugmentsThe Architect Role Augments the MSF Team Modelthe MSF Team Model Program ManagementProgram Management TestingTesting User EducationUser Education LogisticsLogisticsProductProduct ManagementManagement ProgramProgram ManagementManagement EnterpriseEnterprise ArchitectureArchitecture DevelopmentDevelopment ProductProduct ManagementManagement
- 35. BusinessBusiness ArchitectureArchitecture ApplicationApplication ArchitectureArchitecture TechnologyTechnology ArchitectureArchitecture Microsoft Solutions Framework InformationInformation ArchitectureArchitecture Enterprise ArchitectureEnterprise Architecture FrameworkFramework ConceptualConceptual DesignDesign LogicalLogical DesignDesign PhysicalPhysical DesignDesign ProgrammingProgramming ModelsModels Database DesignDatabase Design Technology StandardsTechnology Standards IT Principles and GuidelinesIT Principles and GuidelinesUser ProceduresUser Procedures and Tasksand Tasks Real WorldReal World ConstraintsConstraints Scope ofScope of Impact onImpact on CurrentCurrent SystemsSystems Business StrategyBusiness Strategy Functional ModelFunctional Model Critical SuccessCritical Success FactorsFactors Logical Process ModelsLogical Process Models Information and ProcessInformation and Process NeedsNeeds HardwareHardware InformationInformation ModelModel Systems ModelsSystems Models Application ModelApplication Model TechnologyTechnology ModelsModels Business Services ModelBusiness Services Model Dynamic ModelsDynamic Models User Services ModelUser Services Model Data Services ModelData Services Model SoftwareSoftware
- 36. The Enterprise ArchitectureThe Enterprise Architecture Planning ProcessPlanning Process Control and coordination of change,Control and coordination of change, distribution, and integrationdistribution, and integration Facilitates decision makingFacilitates decision making Managed as a milestone-based processManaged as a milestone-based process Results are measurable and visible toResults are measurable and visible to the organizationthe organization Required for successful deployment ofRequired for successful deployment of distributed client/server technologydistributed client/server technology
- 37. Major Components of EnterpriseMajor Components of Enterprise Architecture Planning ProcessArchitecture Planning Process Program and Project Management and Development Process Enterprise Architecture Design and Development Process Business and Financial Management Process Technical Principles,Technical Principles, Guidelines, andGuidelines, and StandardsStandards FinancialFinancial and Businessand Business Models, Guidelines,Models, Guidelines, and Standardsand Standards Business GoalsBusiness Goals and Objectivesand Objectives Technical ObjectivesTechnical Objectives and Goalsand Goals Coordination between these three processes is essential…Coordination between these three processes is essential…
- 38. Enterprise ArchitectureEnterprise Architecture Planning Process ModelPlanning Process Model Deployment Vision/Scope Approved Master Plan Approved Action Plans Complete EXEC UT ON I E ASS SS T M NE PLA N I G N N C SN TR UC I O T ON
- 39. Vision/Scope ApprovedVision/Scope Approved Develop Problem Statement (BPR, SWOT, Mission) Evaluate Emerging Technology Analyze As-Is Processes Evaluate Options Evaluate Current Projects Business Processes Business Objects Current Projects Critical Success Factors Business Processes Business Goals & Objectives Scope = High Priority Area E ASS SS T M NE Vision/Scope Approved
- 40. Master Plan ApprovedMaster Plan Approved Conduct Impact Analysis Set Priorities Communicate Program Vision and Objectives Analyze As-Is Enterprise Architecture Build the Master Plan AS-IS Enterprise Architecture Business Process Legacy Systems Business Processes Business Objects Focus areas PLA N I G N N Master Plan Approved
- 41. Action Plans CompleteAction Plans Complete Develop Action Plans Develop Change Strategies Develop Infrastructure Blueprints Develop To-Be Enterprise Architecture Technology Deployment Plan Projects IT Initiatives IT Initiatives Business Initiatives To-Be Enterprise Architecture IT Strategic Plan C SN TR UC I O T ON Action Plans Complete
- 42. EXEC UT ON I ReleaseRelease Collect Feedback Implement Plan Evangelize Implement First Use Technology Deployment Plan Projects IT Initiatives IT Initiatives Business Initiatives Deployment
- 43. Planning through building can take advantage of fluctuations in business and technologyPlanning through building can take advantage of fluctuations in business and technology IdentifyIdentify changes tochanges to businessbusiness processesprocesses Business Processes Business Objects Assessment ofAssessment of currentcurrent programs & projectsprograms & projects Business goals,Business goals, strategies,strategies, objectivesobjectives IdentifyIdentify priorities,priorities, risks,risks, and impactsand impacts Critical Success Factors Business Procedures Business Goals & Objectives High Priority Area Technology Deployment Plan Projects IT Initiatives IT Initiatives Business Initiatives AS-IS Enterprise Architecture Business Process Legacy Systems Business Processes Business Objects Adjust Scope andAdjust Scope and gauge impact ongauge impact on applications andapplications and infrastructureinfrastructure To-Be Enterprise Architecture IT Strategic Plan Coordinate legacyCoordinate legacy systems shutdownsystems shutdown and theand the introduction ofintroduction of new businessnew business solutionssolutions I IV III II Planning Cycle
- 44. General PrinciplesGeneral Principles Build a vision for the futureBuild a vision for the future Build the architecture incrementallyBuild the architecture incrementally Focus on common infrastructuresFocus on common infrastructures Utilize Project Management desciplinesUtilize Project Management desciplines in Architecture Projectsin Architecture Projects Staff with the right level of expertiseStaff with the right level of expertise Document, model, and share resultsDocument, model, and share results Involve customers through out theInvolve customers through out the processprocess
- 45. Organizational redesignOrganizational redesign The organizational models chosen for IT Organizations must have give them the ability to : a) develop leveraged partnerships with the business units b) respond rapidly to changes in the business environment
- 46. 48 The Federation ModelThe Federation Model A new paradigm for IT governanceA new paradigm for IT governance Corporate ITBusiness Units Business Units Business Units Business Units Corporate ITBusiness Unit IT Business Unit IT Business Unit IT Business Unit IT Business Unit Business UnitBusiness Unit Business Unit Move Ownership, Responsibility, Autonomy, and Accountability for Business Applications to the Business Units
- 47. ConclusionsConclusions and Lessons learnedand Lessons learned For both organization and architectural teamFor both organization and architectural team The simplicity and elegance of architecture canThe simplicity and elegance of architecture can be deceivingbe deceiving Communications Learning is essential Extremely importantExtremely important Extremely difficultExtremely difficult Rapid shallow cycles are best
- 48. Issues on the HorizonIssues on the Horizon What’s in, what’s out ?What’s in, what’s out ? What does it mean ?What does it mean ? Where can I find…Where can I find… Semantic integrationSemantic integration Inventory controlInventory control Ontological management and control PS, If you plan on going Object Oriented your going to need an Ontology management system real bad!
- 49. Where to get moreWhere to get more informationinformation Forth coming White PaperForth coming White Paper “Architect’ Office”“Architect’ Office” Microsoft Consulting Services,Microsoft Consulting Services, Microsoft Executive Briefing CenterMicrosoft Executive Briefing Center
- 51. ™
Editor's Notes
- This dissertation, Enterprise Architecture Theory and Practice -- Introducing the Architect’s Paradigm into Microsoft, contains: 1) An examination of the Architect’s Paradigm, the key features, theories, and concepts 2) Correlation across Dwelling and I.T. disciplines. 3) A discussion of Microsoft experiences in the conscious introduction of the Architect’s paradigm and role within the Corporation. And is a summary of a forth coming white paper entitle “Architect’s Office --Introduction to Enterprise Architecture”.
- Enterprise Architecture. It conjures up all sorts of wishes, dreams, ideas, and beliefs. Ask ten people what architecture is and your likely to get eleven different answers. Ask business people and I.S. professionals what Enterprise Architecture is and your likely to see their eyes roll back into their heads, or shake their heads in apathy, or get similar responses to the first question of architecture in general. In short everyone seems to have an opinion as to what is architecture. And has through the years been of great debate, primarily by those whose significant experience with architecture is that they live in a house instead of a cave or on the prairie. Ask what architecture should do however, and your more likely to get a consensus. Architecture or rather the results of architecture and design should result in the rational, efficient, and effective creation of something. That thing in Architectural terms is a “Built Environment”. The rational, efficient, and effective creation suggests a process with some logical rules to follow which will result in accomplishment of the objective creation of a “Built Environment”. This the essence of Architecture and what this presentation hopes to relate. Within this presentation we strive to give you a flavor of Microsoft’s efforts in Enterprise Architecture. Key to this initiative is the introduction of the Architect’s Metaphor into Microsoft WWIT.
- This presentation has as it’s goals: 1) The examination the Architect’s Metaphor 2) Overview of the introduction into the Microsoft corporation of Enterprise Architecture In order to accomplish this presentation will explore what is Architecture in general, its’ purpose, processes, and elements. Next, the Architectural Metaphor will be examine as it applies to Enterprise, drawing correlation between professionals involved with the development of Dwellings and Physical spaces with those tasked with the design of Enterprise. After setting this foundation, the presentation will switch to experiences within Microsoft introducing the concepts discussed within this Metaphor. Lastly, these experiences will be summarized into conclusions and lessons learned regarding the introduction and usage of the Architect’s Paradigm.
- Many people are unaware of Architecture, except from watching the father on the Brady Bunch or their experiences within thedwellings they inhabit. From this sheltered perspective it is easy to miss a significant part of Architecture and the Architect’s role. In order to gain an understanding of this Metaphor or Paradigm we’ll first present one definition of the term Architecture, next discuss elements which comprise Architecture, then relate the role an Architect plays through disscussions of Scope and Architectural theory.
- What are the elements of architect: The forces of Chaos and Order. An Architecture and the Architect engaged in the practice transmutes chaos into order through the creation of structure. He does this through the search and application of patterns. He does this within multiple levels of hierarchies within hierarchies. Once through this maze an architect emerges with simplicity...
- Architecture, simply stated, is a set of rules that determine the choice, usage, and organization of elements to create a “Built Environment”. This environment is a designed context in which human needs were used as a rationale for it’s structure and construction. It is important to distinguish between Architecture and the product of design which is based upon an Architecture.
- Drawing manage design complexity through reduction. A drawing is one representation of the design of a built environment. That representation, in the interest of clarity, has a reduced set of information. This reduced set, commonly called a view, contains only that which is relievant to describing a group of attributes under examination.
- Thus to describe a “Built Environment” adequately several drawings, each representing differing views. Each drawing presenting differing aspects of the environment to be constructed. Typically these drawings share the same dimensional systems in Dwelling Architecture to enable cross referencing.
- Environmental Architecture Scope In Environmental Design an Architect operates at a specific level within a hierarchical context. This hierarchy defines the scope through two dimensions: Granularity Span In this example Architects involved in dwelling or structural design work on organizing space into useful forms at a much smaller span than urban planners, but with greater detail or granularity.
- From left to Right Simply put, an Architect starts with some fundamental theories on the world, what it contains and how to make decisions within his domain. From here other theories are developed implicitly or explicitly (usually the latter) which explain why the domain is or works the way it works. Based upon these theories and principles a set of other theories are developed. These working theories typically prescribe a specific approach or view of how to organize the domain. It is from these working theories that the Architect draws upon to create his / her praxis (practice). Located within the praxis are the activities and creation of artifacts typically associated by laypersons with Architecture. These include the mystical design process, drawing process, construction activities. Examples of artifacts are Floor plans, Site plans, Elevation, and Schedules and Detail drawings.
- When Enterprise Architecture is discussed often it is in the limited context of Information Technology (I.T.). While this is primarily a dissertation on Information Systems Architecture, it is the author’s contention that to effectively design or construct an Information System for an Enterprise the context in which that system will reside must be established. That context is the Total Enterprise. Architecture, from the definition stated previously is a set of rules that determine the choice, the usage, and organization of components to create a “Built Environment”. This environment is a designed context in which human needs were used as rationale for it’s structure. An important point to make at this time is that Architecture is not: 1) Drawings a draftsman produces, though they reflect an architecture. 2) The stone, glass, and wood or the space and light in a Gothic Cathedral. Rather it is the heuristics behind the choices and uses of these elements which comprise the fundamental core of Architecture. Unlike dwelling architecture the dimensions of Enterprise, given our current notational systems and limited abilities to express these concepts in a spatial terms, do not necessarily relate between views.
- In Enterprise Architecture these exists a similar hierarchy. Program designers fulfilling a similar role as product designers, Application and System Architects, and then Enterprise Architects operating in much the same capacity as a Urban or Regional Planner. At this level, the details of how an application is constructed is not as important as the flows and the lifecycle of the technology in context to the whole functioning enterprise are.
- Definitions alone do not constitute an enterprise architecture. It is an evolving and dynamic process that helps capture the best practices of an organization. To accomplish this goal requires a process model and dedicated people to assure that deliverables are used effectively. We have applied the principle of “planning through building” and adapted the Solution Development Discipline’s process model to architecture planning. The role and responsibility of the architect augments the solution development team.
- The role of the rational enterprise architect is to successfully implement the architecture. The architect is responsible for coordinating the integration and distribution of complex business systems. The team model for developing an enterprise architecture resembles very closely the SDD team model as described earlier in the presentation. Product Managers for the architecture team assure that the needs of the business are being met - as usual. User Education has a much more expansive role and must be up to date on instructional design, organizational change management, and performance support. The Enterprise Architect fills a dual role of Program Manager/Development. In fact, each architectural track may have its own Program Manager focusing on their own particular part of the enterprise architecture: Business Architect Application (Systems) Architect Information Architect Technology Architect Responsibilities can be delegated to different roles (i.e. Program Management, Development leads).
- The role of the rational enterprise architect is to successfully implement the architecture and to facilitate solution design teams in making design tradeoffs. The architect is responsible for coordinating the integration and distribution of complex business systems, and facilitating the decision making processes for key enterprise management. The organization’s commitment to enterprise architecture planning may be the use of an experienced designer or manager to coordinate architecture activities. Alternatively, a team, based on the SDD team model, may be assigned to coordinate the architecture activities. A lot depends on the size and sophistication of the enterprise. The responsibilities of the enterprise architect may include: Assessment of the alignment between the business and technology goals. Development of the blueprints that assure the to-be technology architecture aligns with the business goals. Design of the infrastructure to support the execution of business applications and systems. Delivery of both business and technical advice, and can influence key decision-makers. Coordination of the technology, information, and application needs of the enterprise. Ownership of the architectural processes and deliverables. Evangelism the enterprise business and technology objectives. Assistance in setting priorities for new solution development projects.
- In organizations that have mature solution development processes, architecture planning is not necessarily distinct or separate from individual projects. It is well integrated to achieve high efficiency and effectiveness. Architecture planning is a process that begins by taking business strategies and objectives, and applies real world constraints to achieve a business/technology solution. Real world constraints include: legal, resource limitations, locality and culture, technical limitations, etc. Solution development begins with strategic planning and establishment of a clear vision and mission for the enterprise. It moves on to development of logical models that represent ideal solutions to a particular problem. Then the architecture process is complete when physical or real world constraints are applied to produce achievable solutions. Each architecture perspective provides standards, guidelines, and models to make conceptual, logical and physical design more efficient and more closely integrated to the business objectives.
- Enterprise planning and architecture development is a critical success factor for deploying enterprise wide client/server systems. Client/server by its very nature is more complicated and difficult to manage based on numerous variables such as: heterogeneous, mixed vendor environments where no one vendor provides a complete solution. business needs based on a perpetual need to re-orient processes to combat ever changing market conditions. lack of mature technologies to support transactions, messaging, workflow, and integration of legacy data and functionality.
- Objective: Identify overlaps between current projects Identify interfaces and dependencies between projects and business initiatives Evaluate synergy of current and future solution development programs. Document the issues and risks, and identify Critical Success Factors. Techniques: Facilitated Sessions & Interviews with Customers, Executives, Functional Managers, and Domain Experts. Map Current Programs and Projects to key business processes & business objects Prioritize objectives and use SWOT, Nominal Group Techniques, Multi-voting, Potential Problem Analysis to make rational decisions (see the Joiner Team Handbook)
- Objectives : Develop the master plan to close down existing system/applications Develop implementation strategies and migration plans for new applications and business processes. Develop a technology deployment plan Techniques: Analyze As-Is Architectures. Develop To-Be Business, Information, Application and Technology Architectures Partition and assign components and services in Application Architecture to the Component Builder and Solution Builder teams. Partition Technology, Information & Technology Architecture to guide infrastructure programs. Engage key stakeholders at visible milestones to obtain visible sponsorship of the plans
- Objective: Gather the cross-functional experts to address the priority problem areas. Develop the action plans to guide the first implementation of the architecture -driven projects. Develop the change strategies that affect people, skills, organizational structure, infrastructure, etc. Techniques: Simple to use tools to facilitate visualization and validation of the solutions. Good, solid project management discipline.
- Objective: Ensure that the implementation plans account for operational constraints and schedules. Ensure User Education, Logistics, and Product Management are ready to go. Implement by a phased role out if practical - to mitigate disruption and uncontrolled changes. Technique: Ensure solution development programs have ongoing, visible sponsorship. Ensure that development programs remain coordinated with the business objectives Review the plan with customer to anticipate changing business needs.
- It’s like changing a tire while going 60 MPH. Organizations are in a constant state of change with numerous programs and initiatives well underway along with requirements gathering or strategic analysis. The enterprise architecture planning process should leverage the work that has already been accomplished in gathering data and prioritizing the users needs. The following steps can be taken: I. To analyze the context and relationships between programs and projects we would map the scope of the programs and projects on a matrix of high level business processes and business objects. This mapping will help to identify the following: a: overlaps between programs/projects on the same business objects and business process. b: interface or dependencies between the programs and projects. II. Analyze the changes in business processes and the critical success factors for implementation. III. Identify the priorities and impacts on the legacy systems and business objects. Some may need immediate attention by virtue of its capacity or current condition. Others may need immediate attention due to eminent business process changes. IV. Develop To-Be architectures based on priority and constraints.
- Tools to Analyze ad Align Enterprises such as Business Analysis System and Environment B.A.S.E. © 1993 B.K.Seitz & Associates
- Architectural Communications is extremely important, It’s also extremely difficult for a broad spectrum of reasons: It appears simple, just a bunch of pictures Terminology is complex or used imprecisely Executive management may understand, but doesn’t have the bandwidth to address. Middle management hasn’t the time to sharpen the ax of organization, we have to cut something now. Peers will not understand and therefore will be conservative in their participation least they show their ignorance. P.S. some may even challenge the validity or quality of architectural work to avoid addressing issues which they feel they should know. Keep an open mind, both the organization and the architectural team will learn a lot. In areas you may not even expect. Remember, this is a technical initiative concerned with how people’s environments are organized. Rapid, Shallow cycles are best. In this area grand plans have yielded grand disasters.
- Key to developing an effective Enterprise Architecture is maintaining Ontological control. This is nothing more than understanding what is within this world, what’s out, and what is its’ purpose. To manage the ontology various technologies can be used: DBMS, Configuration Management systems, Repositories, and yes plan old paper and pencil can help. The primary challenges involved with the management of this ontology is that since the domain is abstract, no physical embodiments can be viewed for clarity. Thus diagrams and definitions are critical elements that represent the Enterprise design and architectural concepts. This infers several issues ahead, as architecture becomes more wide-spread: Storage and retrieval of Architectural material: Categorization & Classification, Indexing, and Access Semantic conflicts: Two names for the same component, The same name for more than one or similar elements Replication and propagation: Creation and/or storage within the Enterprise of the same entity multiple times in an unconscious manner. An excellent example of this issue had risen in the CAD/CAM field during the 80s’. Management much to their horror discovered Designers recreating angle brackets in the hundreds, rather than reuse and existing part. The cause of this phenomenon was the lack of an adequate library of standard parts, search systems or classification and code schema for indexing parts for retrieval. The end result was it was easier and faster to create from scratch than it was to search for the existing material and thereby receive the benefits promised by CAD/CAM systems. Still today aerospace vendors are plagued by this issue.