Cyril Plisko wrote:
> Hello
>
> I have a question on ARC procedure:
>
> What is the formal definition of case inception ?
The short answer is "an ARC meeting that is not intended to
result in a commitment vote".
Of course, there is a longer answer :-)
When projects feel ready to "talk about their architecture",
they schedule an ARC meeting. The most common reasons
for meeting with the ARC are:
P) We just want to talk - we need to know more
about the ARCs and the ARCs need to know more
about us. We tend to call this kind of meeting
a "pre-inception review"; typically they involve
just the project submitter and the proposal
that was submitted. They rarely take more
than 15 minutes.
I) We have some specific questions and unknowns
to hash out - we don't yet have a complete
architectural spec, but hope that this meeting
will get us closer to that point. These
types of meetings are called inception reviews,
and a project can have as many as it needs.
C) We believe we have a solid architecture, and
want the ARC to review and approve it This
approval signifies a commitment by the project
team that the architecture is suitable for reuse
by the larger OS.o meta-community and a commitment
by the ARC that it will manage the future
evolution of that architecture in a way that is
consistent with the expectations set by this
project. This commitment is needed because
other parts of that community will begin to
depend on this architecture; if it were to
change incompatibly in the future, things will
break. For some reason we tend to call these
"commitment reviews" :-)
All cases conceptually follow the normative path
Pre-inception => Inception => Commitment,
though the quantity of meetings that are actually needed varies
with the experience of the project team and the familiarity the
ARC has with the subject matter.
A simple case brought by a project team with past ARC experience
may go directly to "C"ommitment, skipping any sort of inception.
(these are also known as "fasttracks")
A complex case, with an experienced team that is unclear about
the architectural impact of their efforts may need many
different interactions with the ARC:
P => I => I => I => C => C
(This exhausting path is thankfully rare, but does happen)
Once a project team is ARC-savvy, the norm is I => C, which is
why we talk about the ARC process as having "an" Inception
review followed by "a" Commitment.
> It seems that not every case has it, so when one is needed ?
In the best of all worlds,
Pre-inceptions happen immediately after a proposal
has been submitted; the only materials needed are
the proposal itself. Many times it results in a
project being re-routed as a fasttrack; infrequently
it even results in commitment approval.
Inceptions happen as the project team starts playing
"what-if" with prototypes, customer feedback and the
like. It is important that the project be in a
state where it can easily react to course corrections
that result from a better understanding of the
various constraints that exist.
Commitments should happen well before "code-complete";
the risk of delaying is that there may be some ARC-
required changes that result in non-trivial rework
and/or additional new work. Ask yourself how much
design and implementation effort you are willing to
invest in an unproven/unapproved Architecture?
If your project's architectural impact is easy to articulate,
its scope is manageable, and you have been paying attention
to the systems-level impact of your actions, your only needed
ARC interaction may be with a Commitment review early in your
project's lifecycle.
> What deliverables are expected from project team by the
> time of inception ?
In some cases, the equivalent of a good block diagram with
named arrows (interfaces) between the blocks is sufficient.
So is an architectural level functional spec. Whatever you
have produced for your own use should be reusable for the
ARC review - assuming you actually have something.
After reviewing hundreds (nay, thousands) of projects, certain
patterns become obvious. Inwardly focused project teams tend
to ignore outwardly targeted behaviors - upgrade plans, support
for complex enterprise deployments, versioning, reuse etc are
things frequently overlooked in the push to create something that
simply compiles :-) Over the years, the ARCs have collected a
list of these frequently overlooked systems-engineering questions;
at one point there were 20 of them, so the name "20 Questions"
stuck. While some of the 20Q are things that can't be answered
until coding is nearly complete, many of them are applicable
to inception timeframe reviews. In a sense, the 20Q document is
form of a Functional Spec. At a minimum, the materials should
show that their author had perused the 20Q list and addressed
the applicable items found there.
> What are possible outcomes of inception ? There are cases
> marked "inception held", are there any other possible statuses
> after inception ?
The usual are
Need another inception review
Need new Spec before we can determine anything else
Need to schedule a Commitment
Withdrawn
Approved
Most of the time, the next step is completely in the hands
of the project team - the goal is commitment, but is driven
by the set of "still unknown"s faced by the project team.
-John
