IT Architecture + Method = Saved Project

(c) 2008-2014 by
https://www.linkedin.com/in/dusanjovanovic
::
Method must exist
Diary from the IT trenches
How I architected and implemented a solution for a project gone wrong.
Work In Progress!

(c) 2008-2014
The Scoping
●Clear scoping manages the expectations
●Problem Domain Re-partitioning on all levels.
oKey improvement: Solution Domain Definition
oBalancing act: high profile low cost
●Re-evaluated the Requirements
oFound and engaged the key ‘Actors’
oEngaged external systems stake holders
●My vision vs. commercial reality
oUse existing platform, tools & technologies
oEngage with data-center from the start
 Understand all the faults made
 Discover the untapped potential

(c) 2008-2014
Solution Architecture
The Scope, Actors and Sub-Systems

(c) 2008-2014
Technical Architecture

(c) 2008-2014
Taxonomy :: REST endpoints Architecture

(c) 2008-2014
Method :: The Core of the Success
Core Principles
In order to succeed with an ‘evolutionary’ development cycle I had to ensure that at each cycle of
development the current set of components satisfy the following minimal criteria:
● Architecture Driven
o Based on a consistent architecture. Promote the use of a simplified methodology and a
common project repository.
o Tools! Visual Studio Team Edition. Share Point: for the ever important project experience
storage.
● Complete
o Complete in the provision of the required level of functionality. It is NOT the goal of
‘evolutionary’ development to deliver the totality of functionality required in one cycle;
rather, provide solutions that satisfy a particular business driven or technically driven
scenario.
o I suggested that we utilize the UML “Use Case” technique for modeling these scenarios -
stored in our repository and integrated/ checked against our object models at a later stages
in development;
● Tested
o Risks are recognized and quantified. By building-in an evaluation checkpoint at the
beginning of each EDIT development ‘cycle’ we require that each option to be ‘evaluated’
has a specific statement of its goals and business related requirements.
o Conformance to the testing, to be always used as the ‘sanity’ check for the purposes of
project management and evolution.

(c) 2008-2014
Method :: Iterating Upward
● One segment has one “actor” acting in
one role.
o Evaluator
o Architect
o Builder
o Tester
● Common mistake: team members to
have a ‘secondary roles”. Thus dissolve
the primary focus and weaken the
responsibility.
● Storage of the project artefacts a.k.a
the central project repository.
Project
Repository
Four roles = four “EDIT” segments:
● E-valuation
● D-esign
● I-mplementation
● T-esting
One Cycle is one “Level”

(c) 2008-2014
Method :: Evolution to Maturity
● Upward spiraling through time to maturity
o Sequence of releases after maturity is
reached.
● Each level has four segments:
o E-valuation
o D-esign
o I-mplementation
o T-esting
● Assure necessary method conformance to
start the spiraling.
● Minimal conformance to keep the spiraling.
● In the same time all the project developments
are spiralling in parallel.
o The whole project goes through cycles of
delivering new solutions, or evolving old
ones, when and if needed.
o Each design and implementation artefact
is clearly defined in terms of belonging to
one spiral.
o Parallel development is more manageable.

(c) 2008-2014
Method :: Distribution of Efforts
● Decide: Is maturity point reached.
o Know how to allocate
resources in different phases.
● The big-bang phase should be
proportionally short
● After a 'Maturity Point' moment
allow implementation and testing
resources to “take over”.
● Ensure that development is not
ceremonial and documentation
driven.
● Development is solution driven.
● Ensure there is always a certain
minimal amount of time to spent
in each of the four segments of
each spiralling cycle.
Maturity Crossover
Point

(c) 2008-2014
Method :: The Model
● Main role:
Primary
information
carrier between
cycle segments
and between
cycles.
o And also
between
projects
themselves
● Consistent and
structured
communication
● Central model repository is the most important artefact of the
development environment built to support the whole process.
● Start by establishing the model repository first.
o Each model has to be built in such a way that it is useable
as standalone model.
● Project model is the central repository of all the artefacts a
project delivers.

(c) 2008-2014
Method :: The Implementation
● Never loose the sight of a final solution.
● Never start from a “clean sheet”, from
“ground zero”.
● It is very important to prepare and use
such a software development
environment which is going to
preserve in time all the experiences of
the team and all the key artefacts of
the project.
● They key skill
● Decide on the Granularity: the more coarse set of artefacts
gives less reusability.
● The fine grained set of services gives more reusability but
increases complexity.
o Build an initial and minimal product solution out of a set
of critical components.

(c) 2008-2014
Data Center Reality
Industrialised, componentalized data center design.
One rack is one building block. Each is made of blade servers and shared storage. (HP EVA)
1::Implement & Test2::Deploy3::Secure

IT Architecture + Method = Saved Project

Recommended

Recommended

More Related Content

Similar to IT Architecture + Method = Saved Project

Similar to IT Architecture + Method = Saved Project (20)

Recently uploaded

Recently uploaded (20)

IT Architecture + Method = Saved Project