Few days back we had a discussion about the System
Architecture and System design within the Organization. Discussion had an
agenda itself and first point was about stories that all of us wanted to share
with each other. We had around 14 members participated for the discussion and
it was very active discussion too. Sometimes it is bit nervous to hear about
the things that we did wrong; but still its great know how people felt about
them. Truly I experienced the power of making opportunities to talk about the
things that they asked to work is the past.
In general, senior technical people used to work in System
Architecture and Design stuff and they are the people who take the decisions
most of the time. But the people who are truly implementing them, what’s about
them?. Very rarely we asked about the problems they faced, how they feel after
they worked on the Architecture and the Design we proposed them to work. We
start the projects; people do implement them anyhow and deliver them with lots
of difficulties. Finally once we delivered the solutions we have parties and
gatherings and etc. If you delivered something successfully, people forget
about painful stories behind it and try enjoying the winning moment almost all
the time.
But people who work hard on the things that we asked, also
have lots of painful stories to tell and share with all. Sometimes even though
things went ok, but still people have things to mention in front of the people,
who forced them work on that.
I would like take four key points came up in the discussion
and talk a bit about them in detail.
1. Take all the Architectural Decisions at first
stage is not possible, but let it evolve by the time
2. Re-factor the code after each major releases to
the QA
3. Simple Deployment and it should be decided from
the first
4.Think about data volume from the first, when
designing the Databases
Let Architecture Evolve by the Time
Decide the total architecture of a System (large Scale or
medium scale) is almost impossible at the first phase of the Project. It’s even
not possible if you do the same thing again and again too. Because each times
you find things to improve or enhance while develop the systems.
But any of Software Architecture based one or two very
simple basic concepts (Styles). These concepts we used say as Architectural
styles. Ex Layered Architecture, Service Oriented Architecture, Aspect Oriented
Architecture and etc. System Architecture can be a combination of few of these
basic Architectural Styles. Sometimes we may need to build sort of custom
architectural styles for Our Purposes, and you will not find them in common.
Those we can specify as Domain specific or Application Specific Architectural
Styles.
My opinion here is
that we need to get that basic concepts right at the first stage and let
Architecture to evolve around them. Keeping the concepts simple as much as
possible will allow us to extend the system Architecture and the Design in the
latter part of the Project Life cycle. But you may have a question that to what
extent that we have to finish the Architectural
Implementation at the initial
stage. That’s depends on the feeling
that architect and the team has. If you feel that you architectural
implementation is enough to cater the current system implementation to
accomplish main architectural
goals,
and then stop there for a while.
Re-factor the Core after each Major Release
One of the best points that came out in the discussion, yes
we do re-factor sometime implicitly or explicitly. But here point is about doing
the re-factoring explicitly. Developers hate of doing re-factoring most of the
time, because they loves the code they wrote. May bit lazy to do things or fear
for changes. But still we have to convince this as much as possible.
But avoid re-factoring effort as much as possible; we have to
avoid taking Architectural and Design decisions at the early stages. That’s why
we were talking about letting the Architecture and the Design to evolve by the
time as system implementation goes on.
Simple Deployment and it should be decided at first
Again having things decided too much at the initial stage
might eat our lots of energy for later re-factoring and changes. Yes we need to
have basic style for deployment decided at the first stage. But my point is
that we have to let it also evolve by the time. Once we have system
implementation done to some extents, we know 100% which artifacts we need to
deploy at which places, which time and etc.
Think about Data Volume at the initial Stage
Database is the one of the major building block of the system
for data oriented applications. If you are going to change it by time to time,
system base will be shaken frequently and that can make system unstable. Yes
think about data volume at the start of the project will benefit lot. But at
the same time we should make room for changes too. Mean if we face a situation
where we need to change our database structure, how we are going to make it
with minimum effort, which we have to think at the initial stage.
There were around 40 points came in the discussion and almost
all of them are valuable. Let’s see how it goes in the next meet up.
Lakmal
