This is the third part in continuation to my earlier post Goal
Management -
Goal Management - Goal partitioning for Elaboration phase
The goals that are set in the construction pahse is looking at the business goal of delivering some usable system to the end user or consumer. The goals in this phase are broadly:
* To describe the remaining requirements
* To flesh out the design of your system
* To ensure that your system meets the needs of its users and fits into your organization's overall system portfolio
* To complete component development and testing, including both the software product and its documentation
* To minimize development costs by optimizing resources
* To achieve adequate quality as rapidly as possible
* To develop useful versions of your system (alpha, beta, …)
During the Construction phase, your project team will focus on evolving the technical prototype that you developed during the Elaboration phase into the full fledged system. As a result, your team will:
* Achieve and maintain adequate quality in your work as early as possible
* Develop software models that are sufficient to guide the implementation of your system
* Work closely with your user community to validate that your work meets their needs
* Implement and test the various components of your system
* Develop useful versions of your system as early as is practical
* Baseline the validated components and
* Manage the risks, people, and other project resources effectively.
As you work towards your goals, you will create and/or evolve a wide variety of artifacts:
* Revised requirements model (use cases, supplementary specifications) describing what you intend to build
* Revised project−level software architecture documents (SAD)
* Detailed software design models showing how your system is built
* Executable system ready for beta release to your user community
* Revised project schedule, estimate, and risk list from which to manage your project
* Revised team environment definition (tools, processes, guidelines, standards, etc.) indicating the tools and techniques that your team will use
* User, support, and operations documentation that is ready to be beta tested.
Goal Management in iterative development process is a multi step process. Starting from partitioning the goals into phases and then from phases to iterations is a critical process.
Goal partitioning into phases:
The phases are Inception, Elaboration, Construction and Transition. Now how to partition the goals of the project into these phases? Let discuss it from phase to phase:
1. Goal partitioning for Inception phase
Inception is a phase in which the team basically identifies the requirement for the system. This is the phase in which the feasibility of the project comes up. It gives insight to the complexity of requirements and possible technical challenges. So which goals are to be partitioned into this phase? The primary objective of this phase are:
* To describe the initial requirements
* To develop and justify the business case for the system
* To determine the scope of your system
* To identify the people, organizations, and external systems that will interact with your system
* To develop an initial risk assessment, schedule, and estimate for your system
* To develop an initial tailoring of the Unified Process to meet your exact needs
The primary goal of the Inception phase is to set a firm foundation for your project. To accomplish this, we will need to:
* justify both the system itself and your approach to developing/obtaining the system,
* describe the initial requirements for your system,
* determine the scope of your system,
* identify the people, organizations, and external systems that will interact with your system,
* develop an initial risk assessment, schedule, and estimate for your system, and
* develop an initial tailoring of the Unified Process to meet your exact needs.
So if we look at this, this phase actually adds to the goal of the project itself. It basically provides input and a base for the rest of the phases. The artifacts that might come out of this phase are:
* A vision document
* An initial requirements model (10–20% complete)
* An initial project glossary
* A business case
* An initial domain model (optional)
* An initial business model (optional)
* A development case describing your project's tailored software process (optional)
* An architectural prototype (optional)
So if we try to partition our project goals to this phase, we shall have to take up those goals that are primarily for the achievement in business functionality. But we can not take out rest of them. So we hardly partition the goals in this phase. We on the other hand give concrete form to the project goals in this phase.
Eh! There is something interesting to read and learn. We here
also are in the way of architecting in a big way already. I am reproducing this
post from MSDN.
A-Z Guide to Being an Architect
A Is for Advocate
“I think you’ll find that you really don’t want to do it
like that.”
Architects have to explain and advise on technical issues to
business stakeholders. They also have to be able to advise delivery teams on how
to build. This advice is the currency of an architect; invested wisely, it will
return goodwill and trust. The architect is asked for advice, because it is the
architect’s job to “see the whole.”
See also: Abstraction, Agile, Acrobat, Availability,
Analysis, Applications
B Is for Balance
“A little more to the left. Keep going. A bit more. Not
that far. Sorry.”
All decisions involve trade-offs—for example, adding a
security measure may hurt performance. It is the architect’s lot to make the
right trade-off. Architecture may be a zero-sum game, but knowing what the
system is intended to achieve enables the architect to choose the trade-offs
that make the system successful. Of course, where there are competing
objectives, it falls to the architect to explain the issue and seek resolution
through prioritization of the objectives.
See also: Best Practice, Benchmarks, Building
Blocks
C Is for Coach
“Work through the pain!”
With so many choices for the implementation of a solution,
architects cannot simply dictate to development teams their notion of the
“architecture.” They are now called upon to coach development teams. Softer
skills are needed: asking how and why rather than instructing “do this” and “do
that.” This is a Good Thing. Development teams who understand the reasons for
the architecture are more likely to commit to it and are likely to do a better
job of implementing it. Architects can also begin to spot talent within
development teams and offer useful career progression opportunities.
See also: Communication, Champion, Context,
Collaboration, C#
D Is for Dependencies
“What happens if I unplug this? Oh!”
The relationships among the components that make up
anarchitecture are of fundamental importance. Dependencies are inevitable but
should be as few and as manageable as possible. Draw a diagram and map the
dependencies. Circles, whether direct (A depends on B and vice versa) or
indirect (A depends on B which depends on C which depends on A) are a Bad Thing.
If many things depend on D, then D needs to be stable because changing it will
have a significant effect.
See also: Design, Development, Delivery, Domain,
Documentation
E Is for Evangelist
“Let me show you something really cool.”
Architects need to be advocates for the choices they have
made; others need to believe in the ideas, frameworks, and guiding values of an
architecture. Evangelism is about telling stories to different people. A simple
segmentation may be a technical versus business audience, but there are really
many differing audiences within that. The architecture needs to have a
compelling story for each. An evangelist is able to synthesize and simplify
complex scenarios for the benefit of common understanding.
See also: Enterprise, Engineer, Enthusiast
F Is for Frameworks
“How do I get there?”
Creating the architecture for a solution may be difficult.
Creating the architecture for multiple solutions is harder—especially, given
time pressures and the integration between solutions. An architecture framework
is a structure that removes some of the wheel reinvention that would otherwise
occur. It provides tools, methods, and a common vocabulary for the process of
creating an architecture. An architecture framework can be considered to address
the how of architecture.
See also: Facts, Functionality, F#, Firewall
G Is for Governance
“It is the opinion of the subcommittee…”
There comes a time, as they say, when you have to put on the
suit if you’re serious about doing business. Control is an important part of
realizing an architectural vision. Regardless of the model of IT—centralized,
decentralized, or federated—there will be competing requirements of equal value.
A good architecture needs to be able to flex to differing needs, but not so much
that the values of the architecture are lost to the immediate, possibly
short-term, must-haves of the business. Equally, good governance can give a
positive, dashboard-style view on technology for the business. Common
understanding is always a Good Thing.
See also: Generative Programming, Generalist
H Is for Human Dynamics
“The system would have been a success if it hadn’t been
for those pesky users!”
Understanding how people interact with each other and the
systems that support them is crucial to delivering successful solutions. The
dynamics of each project and team will be different; the stakeholders’
relationships and motivations may be unique to a given project. Knowing how to
navigate human relationships is a key skill of good architects and good
leaders.
See also: Heterogeneous Environments, Heated Debates,
High Performance Computing
I Is for Innovation
“The lifeblood of any organization”
Most products can be viewed as a cycle of invention,
innovation, commoditization, and redundancy. Invention is costly, slow, and can
require luck and big leaps in thinking. By commoditization time, the game is up,
and harnessing the work of others is probably the best option. Typically,
therefore, it is the innovation space where advantages—efficiency, competitive
differentiation, and so forth—can be achieved through perhaps smaller, but no
less valuable evolutions and revolutions of existing ideas and solutions. Small
teams can push for innovation constantly and take chances to make their name.
Larger groups and organizations may not be able to move as quickly, but they
need to enable innovation to percolate from individuals and teams and develop
mechanisms for making the best of this inspiration and imagination. Architects
can be the mouthpiece for the technical teams, and the ears of the business for
innovation.
See also: Integrity, Inspiration, Infrastructure
J Is for Judgment
“With great power comes great responsibility.”
When the discussion is done and a technical decision must be
made, then an architect is going to have to exercise judgment. The team entrusts
the architect to make these judgment calls, and the architect’s good judgment
gives confidence to the team. For better or for worse, a series of good or bad
calls may be seen to characterize the architect: conservative or wise, impulsive
or prescient, biased or brave. Exercising good judgment is vital, but in
practice, even good judgment will sometimes turn out to be wrong. Don’t worry
about making a mistake; worry more about not doing anything.
See also: Java, Just In Time
K Is for Knowledge
“If only I knew then what I know now.”
Knowledge is a key architectural tool. Of course, being aware
of the boundaries of your knowledge is a Good Thing. Areas that are known
unknowns are ripe for proof-of-concepts and other knowledge-building exercises.
Unknown unknowns, on the other hand, are Bad Things: They are the architectural
equivalent of gremlins. Knowledge of technology is only one, albeit important,
domain that an architect needs to command. An architect also needs to know about
the nontechnical factors that will be in play, such as organizational
structures, enterprise strategy, business processes, and development
methodologies.
See also: Kernel, Keyboard
L Is for Leadership
“I’m behind you all the way.”
Leadership is vital for an architect and typically takes two
forms: thought leadership and team leadership. As guardian of the architecture
and the values behind the architecture, the architect is thought leader: The
architect continually reevaluates the vision and re-presents the “newer,
shinier” vision, with comment on competing visions and emerging technology. As
team leader, an architect may not be required to perform line management duties,
but may be called upon to be an icon for the rest of the team, providing
confidence, insight, motivation, and inspiration.
See also: Lean, Linux, Latency, Load Balancing
M Is for Modeling
“So, to help us visualize how this might work, I made
this model using nothing but twigs and guitar strings.”
A model is a representation of something—for example, a
business process or computer system. Views of a model provide a way to
communicate and understand ideas about the problem and the solution. Different
views address different concerns—overloading one view in an attempt to address
multiple concerns will either lead to an overcomplicated view or an
oversimplified understanding. Having a shared notation for representing these
views of a model can simplify conversations about the model—although, if the
notation becomes too complex, this benefit is soon lost.
See also: Management, Maintainability, Messaging
N Is for “N-tier”
“A house of cards”
Data Layer, Business Logic Layer, User-Interface Layer. Job
done. Well, not quite. N-tier is a vague term at best, and doesn’t really say
anything more than pointing to the idea that there should be some kind of
separation of concerns between various chunks of code. With Service-Oriented
Architecture (SOA), and, most recently, the explosion in cloud services—either
as back end (cloud storage for example) or front end (such as Facebook)—actually
describing the architecture can be harder than building it. We’re fans of the
“Petri dish” approach: concentric circles usually containing square boxes as if
suspended in agar jelly.
See also: Needs, Networks, Nonfunctional Requirements,
.NET
O Is for Object Orientation
“Encapsulate this!”
Object Orientation (OO) is a programming paradigm that rose
to prominence in the 1990s. It can be thought of as a way to conquer complexity
by dividing a big problem or program into bite-size, digestible, and, of course,
logically coherent chunks. Object orientation is often referred to as OO and
sometimes as OOP (Object-Oriented Programming), which is only a letter away from
sounding like a mistake. To ensure acronym coverage, we must also mention OOAD
(Object-Oriented Analysis and Design). Object orientation is as much an analysis
technique as it is a programming paradigm, although translation is often
required from an analysis, or conceptual, model to a design, or logical,
model—just as there is between the design model and the implementation, or
physical, model. An object—the entity at the core of OO—has both behavior and
data, and the functionality of a system is achieved through the interaction of
objects. Objects, which are instances of classes, expose their abilities via
methods. There are, predictably, some key concepts and terms to be learned in
order to grasp OO—the most important being inheritance, polymorphism,
encapsulation, and abstraction.
See also: Operations, Object-Relational Mapping,
Operating System, OLAP
P Is for Patterns
“I think I see something emerging from the chaos. Is it a
zebra?”
Patterns are everywhere it seems. Where there was the Gang of
Four and their original Design Patterns, now there are many resources and books
dedicated to patterns across many disciplines. Some are stronger than others and
probably some judicious pattern-weeding is necessary for a well-maintained
architectural garden. Patterns provide both a template for the implementation of
a particular concept but also a common language to discuss abstract and complex
concepts without the need to resort to a full description, or a diagram—although
we’d probably do that, too.
See also: Principles, Platforms, Politics, Performance,
Process
Q Is for Quality
“Good enough isn’t good enough.”
Quality is often understood as a synonym for good. Good is
hard to define and measure. Quality should be defined and measurable. What
quality is really about is ensuring that the solution meets the requirements and
all the applicable standards (as defined by the enterprise, industry, statutory
authority, and so forth). By defining and specifying the metrics and standards,
a solution can be judged—and, if necessary, improved.
See also: Qualifications, Queries, Quantification,
Quantum Computing
R Is for Road Maps
“You take the high road, and I’ll take the low
road.”
Where architecture and real life sometimes come unstuck is in
the difference in times between the production of concepts and the subsequent
realization of the vision. Many obstacles stand in the way of a beautiful
architecture: differing views, changing product strategy, short-term tactical
needs. A road map can help to maintain the original vision, providing a view on
the now, the soon and the later of the implementation. A road map can provide
the business with a view on the plans and targets of the technology teams. A
road map can sometimes help you remember just what it was that you were trying
to do in the first place.
See also: Requirements, Realization
S Is for Strategy
“What are we trying to achieve?”
Strategy sets out how to achieve your goals. Architectural
strategy is derived from the enterprise strategy—it should enable the enterprise
to achieve its goals. The word “strategic” should be used with care and
caution—many before you have used it to justify costly, long-term investments
with ill-defined benefits. A strategy, like a good military plan, should be
adaptable—otherwise, it will collapse upon contact with reality. Strategy is
often confused with—and sometimes mistakenly thought to be in opposition
to—tactics. Tactics are the specific actions that, by achieving objectives, are
the implementation of your strategy.
See also: Services, Software, Standards, Security,
Scalability
T Is for Thinking
“I think, therefore, I clearly have too much time on my
hands.”
As a skill, thinking is typically not a problem for
developers and architects. Finding the space and time to think is a little
harder. In these days of a constant bombardment of information from the
blogosphere—good, bad, and ugly—it can sometimes be hard to find the inclination
to think for oneself. Such a crucial activity needs to be given focus and an
architect should be prepared to make the space and time and defend it. Think
about thinking: What works for you? Long train journeys? Music? A hot bubble
bath? It might be hard to install a bathroom suite in the office, but you never
know.
See also: Technology, Transparency
U Is for Understanding
“I do believe you’ve got it.”
Understanding is complementary to knowledge. Understanding
people, systems, and processes makes a significant difference to the outcome of
a solution. It is the antithesis of assumption. Some nefarious types will
present assumption as understanding; this is undoubtedly a Bad Thing and will
not lead to the Promised Land of Good Architecture. Questioning is a key
technique for reaching understanding; used well, it can puncture assumption,
myth, and other forces that could derail a project.
See also: UML, Unix
V Is for Values
“Explain to me again why we’re doing this…”
The values of an architecture are best expressed as
principles—the value system that guides decision-making and architectural
practice is made up of these values. Principles are, therefore, the foundation
that underlies architecture. To be effective there should be no more than a
handful of enterprise-level principles and they must have the support of senior
leaders. A good principle is clear, consistent, relevant, appropriately focused,
adaptable, and stable.
See also: Virtualization, Visualization, Views
W Is for Whiteboard
“It’s probably easier if I just draw a picture.”
Good whiteboarding skills are a true art: It is easy to
become an apprentice, but achieving mastery is always elusive. On the evidence
of our own careers, we suspect that many great ideas have never been implemented
simply because of a “bad gig” on the whiteboard. In the future, if the original
pioneers of computer technology are to be remembered (that’s you, by the way)
then the most fitting monument would be a huge statue of a whiteboard in
pristine white marble, with just a few tell-tale signs of the accidental use of
a permanent marker.
See also: Workflow, Wikis, Windows, Web
X Is for XML
“<xs:element name=’quote’ type=’xs:string’
/>”
XML has become a universal markup language; thus, providing a
nonproprietary format for data storage and a means to integrate systems and
applications. While it has its detractors and there are rival markup languages
(such as JSON and YAML), there is, as yet, nothing that can rival the reach of
XML. While some may think of XML as the Esperanto of the Web, it is really
nothing more than the basis for a shared language. Think of XML as providing the
letters and the punctuation, but not the words or grammar. XML Schema (XSD)
provides a means of defining XML documents that can be shared and used to
validate documents. And, while there are alternatives, such as RelaxNG, XSD—like
XML—has sufficiently broad reach that it is likely to be understood by partners
and customers.
See also: XSD, XPath, XQuery, XAML, XOML
Y Is for YAGNI
“Stay on target! Stay on target!”
Great designs are often not grand designs. Using good
judgment to decide when to build new features, or reuse prior work, or skip the
features is all part of the architectural game. Still, it can be appealing to
keep just building new stuff, just in case it’s needed in the future, because
“you never know.” Of course, you do know; not much software lasts for all that
long these days, owing to new techniques, channels, and even languages that can
be exploited. If you’re not sure, more than likely, You Ain’t Gonna Need It.
See also: YAML, Yottabyte
Z Is for Zeitgeist
“All the cool people are doing it.”
Zeitgeist or “spirit of the age” is an important aspect of
thinking and values and leadership. It’s magnified with the rate at which “ages”
manifest themselves. We’re already on Web 2.0 after all. Understanding how to
react to the zeitgeist ensures that the right steps are taken to respond to
changing circumstance: “Let’s reinvent ourselves as Facebook tomorrow.”
Typically, for an architect, it is not so much the manifestation of new
thought—those are just implementations—as the underlying memes and their
importance in the technology landscape. Everyone else sees “social networking,”
where an architect sees “the semantic Web.”
See also: Zeal, Zettabyte, Zero Day Exploit