Use of Architecture For Engineering Systems The Good, The Bad, and The Ugly
Uploaded by
incosewmaUse of Architecture For Engineering Systems The Good, The Bad, and The Ugly
Uploaded by
incosewmaUse of Architecture for Engineering Systems;
The Good, The Bad, and The Ugly
Gundars Osvalds
Technology Fellow
Red Arch Solutions
gundars.osvalds@redarchsolutions.com
July 12, 2006
Agenda
Architecture Perspectives
Use of Architecture
The Good; The Bad; The Ugly
Architecture Development Issues
The Curse of PowerPoint
Use and Misuse of Tools
Contractor Responsibilities
Customer Participation
Conclusion
Architecture Perspectives
The Emperor’s New Architecture by Gundars Osvalds
Look at my
I love Its progressing nicely. great
architecture.
architecture! It is
Can you
incomparable
create me a
!
new one?
I am using
I will create the best of
© Gundars.Osvalds@RedArchSolutions.com
you a great Emperor breed
architecture frameworks
! . I need
more gold Emperor
Manager
to finish.
Emperor I do not
But its not
recognize the I am
an
architecture, but determine
architecture!
I can’t let on. d to see
Contractor this
It will show through,
FRAMEWORKS:
everyone after all I
FEAF, DoDAF,
my am the
TOGAF,
greatness! Contractor Emperor.
Zachman
Architect
Use of Architecture
Emperor
To represent the needs of the Stakeholders
Provides information on which decisions can be
made
Models business concepts
Basis for effort cost and schedule estimates
Supports definition of objectives
Create component specifications used in
implementation
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
Before a Federal program is approved an
architecture is required
• The 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 Budget
Industry has developed architecture frameworks to
be used as architecture development references
• The Zachman Framework, referenced by DoDAF, FEAF, and
tool vendors
• The Open Group Framework, supported and used by
industry consortium
The Bad
Focus is on delivery of products not results
It’s a paper exercise not focused on addressing
• 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.
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
The Ugly
Many times engineering principles are not followed
Frequently architecture processes are ignored or not
understood
If architecture doesn't produce results it will be “de-
funded”
There is a lack of:
• Planning and vision of what architecture products and processes
are needed,
• Management support,
• Technical oversight and control,
• Understanding of goals and requirements of system.
Focus is on products, not what architecture goals they
support
Architecture Development
Manager
Issues Architect
Products are defined by management without
understanding or consultation with engineers
• Political needs mandate deliverables
• Products 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)
Consensus does not always provide the desired
solution
• A Chief Architect must be empowered to validate and
verify the results
There needs to be a process for product sign-off
• Products are delivered on whose authority?
The Curse of PowerPoint
Reduces all subjects to a series of bullets
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
analysis”
Two recommended approaches in developing PowerPoint
presentations that are based on the engineered architecture
• Develop conceptual presentation slides and verify against the
architectural products
• Develop architectural products and then use them or illustrate for
presentation
Make sure that story told is consistent with the engineered
products
Use and Misuse of Tools
A tool operator is not an architect
The architect can use a tool operator to develop
the products under their guidance
• It is the responsibility of the architect for the product
deliverable
It is not the tool vendor’s responsibility to define
the process
Diagrams may be incompatible because they are
based on different methodologies
Each tool may have custom implementation of
industry specified diagrams
• Thus diagram interchange between tools may not be
possible
Contractor Responsibilities
Contractor
The Contractor is the Doctor; the Customer is the
Patient
• Listen to the customer; Educate the customer; Propose
solutions,
• Contractors must state their concerns to the customer,
• Satisfying the customer is a delicate balance.
Work with customer to determine their customer
architectural viewpoint
• Such as: Contextual, Conceptual, Business, Logical,
Physical
Customize framework models to address
customer needs
Customer Participation
Emperor
Should be knowledgeable in architectural concepts
Must have an engineering process that defines:
• Which Framework will be used,
• Product description,
• Relationships between products,
• Purpose and user of each product.
Should define project “gates”
• Intermediate results can be evaluated
• Effort should be redone if not satisfied
Conclusion
Emperor Contractor Manager Architect
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
It must be the goal of all that the developed
architectural description is usable for
• Tradeoffs,
• Planning,
• Costing,
• Implementation.
