Presentation is loading. Please wait.

Presentation is loading. Please wait.

Use of Architecture for Engineering Systems; The Good, The Bad, and The Ugly Gundars Osvalds Technology Fellow Red Arch Solutions

Similar presentations


Presentation on theme: "Use of Architecture for Engineering Systems; The Good, The Bad, and The Ugly Gundars Osvalds Technology Fellow Red Arch Solutions"— Presentation transcript:

1 Use of Architecture for Engineering Systems; The Good, The Bad, and The Ugly Gundars Osvalds Technology Fellow Red Arch Solutions July 12, 2006

2 Agenda Architecture Perspectives Architecture Perspectives Use of Architecture Use of Architecture The Good; The Bad; The Ugly The Good; The Bad; The Ugly Architecture Development Issues Architecture Development Issues The Curse of PowerPoint The Curse of PowerPoint Use and Misuse of Tools Use and Misuse of Tools Contractor Responsibilities Contractor Responsibilities Customer Participation Customer Participation Conclusion Conclusion

3 Architecture Perspectives The Emperors New Architecture by Gundars Osvalds © I love architecture. Can you create me a new one? I will create you a great architecture ! It will show everyone my greatness! Contractor Emperor Its progressing nicely. I am using the best of breed frameworks. I need more gold to finish. It is incomparable ! FRAMEWORKS: FEAF, DoDAF, TOGAF, Zachman Emperor Contractor Manager Look at my great architecture! I do not recognize the architecture, but I cant let on. I am determine d to see this through, after all I am the Emperor. But its not an architecture! Emperor Contractor Architect

4 Use of Architecture To represent the needs of the Stakeholders To represent the needs of the Stakeholders Provides information on which decisions can be made Provides information on which decisions can be made Models business concepts Models business concepts Basis for effort cost and schedule estimates Basis for effort cost and schedule estimates Supports definition of objectives Supports definition of objectives Create component specifications used in implementation Create component specifications used in implementation Emperor

5 The Good It is generally recognized that one must develop an architecture to provide a description of how the needs of the stakeholder will be met It is generally recognized that one must develop an architecture to provide a description of how the needs of the stakeholder will be met Before a Federal program is approved an architecture is required Before a Federal program is approved an architecture is required The Department of Defense Architecture Framework DoDAF is mandated for DoD programsThe Department of Defense Architecture Framework DoDAF is mandated for DoD programs Federal Enterprise Architecture Framework and Consolidated Reference Models are required by the Office of Management and BudgetFederal Enterprise Architecture Framework and Consolidated Reference Models are required by the Office of Management and Budget Industry has developed architecture frameworks to be used as architecture development references Industry has developed architecture frameworks to be used as architecture development references The Zachman Framework, referenced by DoDAF, FEAF, and tool vendorsThe Zachman Framework, referenced by DoDAF, FEAF, and tool vendors The Open Group Framework, supported and used by industry consortiumThe Open Group Framework, supported and used by industry consortium

6 The Bad Focus is on delivery of products not results Focus is on delivery of products not results Its a paper exercise not focused on addressing Its a paper exercise not focused on addressing The needs of the Stakeholder, Owners, Users, Developers, Managers.The needs of the Stakeholder, Owners, Users, Developers, Managers. The use of the architecture: Portfolio Management, IT Investments, Identify Duplication and Gaps, Evaluate Business Functions Support, Develop Systems Specifications, Support System Design.The use of the architecture: Portfolio Management, IT Investments, Identify Duplication and Gaps, Evaluate Business Functions Support, Develop Systems Specifications, Support System Design. An architecture process in itself does not necessarily result in a useable architecture An architecture process in itself does not necessarily result in a useable architecture What matters is how one uses it and what results come from it What matters is how one uses it and what results come from it

7 The Ugly Many times engineering principles are not followed Many times engineering principles are not followed Frequently architecture processes are ignored or not understood Frequently architecture processes are ignored or not understood If architecture doesn't produce results it will be de-funded If architecture doesn't produce results it will be de-funded There is a lack of: There is a lack of: Planning and vision of what architecture products and processes are needed,Planning and vision of what architecture products and processes are needed, Management support,Management support, Technical oversight and control,Technical oversight and control, Understanding of goals and requirements of system.Understanding of goals and requirements of system. Focus is on products, not what architecture goals they support Focus is on products, not what architecture goals they support

8 Architecture Development Issues Products are defined by management without understanding or consultation with engineers Products are defined by management without understanding or consultation with engineers Political needs mandate deliverablesPolitical needs mandate deliverables Products become stylized PowerPoint presentations that may not be traceable to the engineered architectureProducts become stylized PowerPoint presentations that may not be traceable to the engineered architecture Need to conform to a specified framework that is not fully defined (i.e., DoDAF, FEA, ZF, TOGAF)Need to conform to a specified framework that is not fully defined (i.e., DoDAF, FEA, ZF, TOGAF) Consensus does not always provide the desired solution Consensus does not always provide the desired solution A Chief Architect must be empowered to validate and verify the resultsA Chief Architect must be empowered to validate and verify the results There needs to be a process for product sign-off There needs to be a process for product sign-off Products are delivered on whose authority?Products are delivered on whose authority? Manager Architect

9 The Curse of PowerPoint Reduces all subjects to a series of bullets Reduces all subjects to a series of bullets Watering down of engineering issues reduces ability of management to make educated decisions Watering down of engineering issues reduces ability of management to make educated decisions The Columbia space shuttle Accident Board concluded that At NASA endemic use of PowerPoint has been substituted for rigorous analysisThe Columbia space shuttle Accident Board concluded that At NASA endemic use of PowerPoint has been substituted for rigorous analysis Two recommended approaches in developing PowerPoint presentations that are based on the engineered architecture Two recommended approaches in developing PowerPoint presentations that are based on the engineered architecture Develop conceptual presentation slides and verify against the architectural productsDevelop conceptual presentation slides and verify against the architectural products Develop architectural products and then use them or illustrate for presentationDevelop architectural products and then use them or illustrate for presentation Make sure that story told is consistent with the engineered products Make sure that story told is consistent with the engineered products

10 Use and Misuse of Tools A tool operator is not an architect A tool operator is not an architect The architect can use a tool operator to develop the products under their guidance The architect can use a tool operator to develop the products under their guidance It is the responsibility of the architect for the product deliverableIt is the responsibility of the architect for the product deliverable It is not the tool vendors responsibility to define the process It is not the tool vendors responsibility to define the process Diagrams may be incompatible because they are based on different methodologies Diagrams may be incompatible because they are based on different methodologies Each tool may have custom implementation of industry specified diagrams Each tool may have custom implementation of industry specified diagrams Thus diagram interchange between tools may not be possibleThus diagram interchange between tools may not be possible

11 Contractor Responsibilities The Contractor is the Doctor; the Customer is the Patient The Contractor is the Doctor; the Customer is the Patient Listen to the customer; Educate the customer; Propose solutions,Listen to the customer; Educate the customer; Propose solutions, Contractors must state their concerns to the customer,Contractors must state their concerns to the customer, Satisfying the customer is a delicate balance.Satisfying the customer is a delicate balance. Work with customer to determine their customer architectural viewpoint Work with customer to determine their customer architectural viewpoint Such as: Contextual, Conceptual, Business, Logical, PhysicalSuch as: Contextual, Conceptual, Business, Logical, Physical Customize framework models to address customer needs Customize framework models to address customer needs Contractor

12 Customer Participation Should be knowledgeable in architectural concepts Should be knowledgeable in architectural concepts Must have an engineering process that defines: Must have an engineering process that defines: Which Framework will be used,Which Framework will be used, Product description,Product description, Relationships between products,Relationships between products, Purpose and user of each product.Purpose and user of each product. Should define project gates Should define project gates Intermediate results can be evaluatedIntermediate results can be evaluated Effort should be redone if not satisfiedEffort should be redone if not satisfied Emperor

13 Conclusion Systems Engineers performing the duties of the Architect must be responsible for the engineering integrity of the architecture products Systems Engineers performing the duties of the Architect must be responsible for the engineering integrity of the architecture products The architect should educate the customers in the development and use of architecture products The architect should educate the customers in the development and use of architecture products It must be the goal of all that the developed architectural description is usable for It must be the goal of all that the developed architectural description is usable for Tradeoffs,Tradeoffs, Planning,Planning, Costing,Costing, Implementation.Implementation. The architecture must be useful to all of its Stakeholders Emperor Contractor Manager Architect


Download ppt "Use of Architecture for Engineering Systems; The Good, The Bad, and The Ugly Gundars Osvalds Technology Fellow Red Arch Solutions"

Similar presentations


Ads by Google