The document discusses the use of architecture for engineering systems and identifies some good practices as well as common issues and pitfalls. It notes that developing an architecture is generally recognized as important to describe how stakeholder needs will be met, but that the focus is often on delivering products rather than achieving results. Common problems include a lack of planning, management support, and technical oversight. PowerPoint presentations can oversimplify issues, and tools should not be substituted for an architect's expertise. Contractors must work with customers to determine their needs, and customers should participate in defining the engineering process to develop a usable architecture.

1. Use 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

2. 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

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

4. 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

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

6. 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

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

8. Manager

Architecture Development
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?

9. 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

10. 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

11. 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

12. 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

13. 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.
The architecture must be useful to all of its Stakeholders