[epf-dev] OpenUP/Basic Architectural Approach

[Jim Ruehlin <jruehlin@xxxxxxxxxx>]

One of the items we discussed in today's review of the OpenUP
Architecture package was changing the approach we take to Architecture
(see https://bugs.eclipse.org/bugs/show_bug.cgi?id=165258). There was
general agreement that we need to be more agile in this area than we are
now, although there's a lot of useful guidance now.

 

Based on our discussion and some other thinking, I put together some
initial bullet points for discussion. The intent is to describe a
lighter-weight perspective for how architectures are created in
OpenUP/Basic. Comments are encouraged.

 

Properties of OpenUP/Basic Architectural Approach

*	It's more important in a small team to start building and
experimenting with architectural ideas early than to do lots of up-front
architectural analysis. This implies short iterations and rapid
adjustments during Elaboration.
*	The architecture is always important enough that it needs to be
documented, even if no other part of the design is documented. It can be
documented through one or a combination of the following:

	*	List of architectural decisions categorized by
viewpoints or other relevant taxonomy.
	*	UML visual model using 4+1 architectural view.
	*	List of interfaces that connect significant parts of the
system
	*	Other simple templates.?

*	The bits of new architecture that are added during an Iteration
must be documented by the end of the iteration, or the iteration hasn't
ended.
*	Refactoring the architecture is an essential activity for most
Elaboration iterations so the final architecture is robust.
*	Tacit knowledge - an expert's perspective that delivers useful
insight and guidance - is an accepted architectural input. For example,
assume Mark is the acknowledged expert on some part of the system. He
may define a set of architectural decisions that are difficult to
justify directly, but his experience tells him it's the right way to go.
It shouldn't be necessary for Mark to provide detailed justifications.
He should only need to provide enough information to gain the support of
the team members. Justifications should be brief if Mark has made good
decisions in the past.
*	The architecture is verified through demonstration, not
documentation.
*	In general, the architecture is the least amount of the design
that can be documented that still illustrates the way in which the
system reifies a solution to the customer's problem.

 

- Jim

____________________

Jim Ruehlin, IBM Rational

RUP Content Developer

Eclipse Process Framework (EPF) Committer www.eclipse.org/epf

email:   jruehlin@xxxxxxxxxx

phone:  760.505.3232

fax:      949.369.0720