... Or to
be more exact, it’s a system of systems. But that doesn't matter; it's still an
information system with moving parts and interdependencies.
That is why
the notion that Enterprise Architecture (EA) shouldn't care about details
doesn't make sense. It's also how so many "ivory towers" were built
and later dismantled.
Failure to
recongise that EA is the same discipline as system
architcture has led to a more or less generalised disappointment with EA. It is
not that there's anything wrong with EA frameworks such as TOGAF. The problem
is that EA frameworks only specify how to organise the work, but not how to do
it. To me a framework is to architecture what a methodology (such as Scrum) is
to development, and not more than that.
In fact I
am of the opinion that TOGAF is really good to support programme management.
“Doing”
architecture means designing systems based on qualities that stakeholders
specify, identifying trade-off points, recommending solutions and strategies.
One of the
newsletters that I like to follow is the one from SQLServerCentral.com. The
editorial that I copied below caught my attention. It’s about something most
have seen before – a story about the ills of micro-management. But why does it
happen so often? Probably the manager knew or at least suspected that a
low-level technical decision such as the choice of backup technology might have
a direct impact on the customer’s experience and hence on the whole business.
While it is often the case that managers get too involved in technical details
and end up wasting everybody’s time (including their own), it also happens
quite a lot that because of what looks like a detail a whole business gets
affected. Some examples: the antenna in the iPhone 4, the brakes of the Toyota Prius a few years ago, the MarsOrbiter crashing. There are many cases where a technical decision has caused
serious problems not only to the system that contained the affected component
but also to the whole environment.
Of course I
don’t claim that architecture can solve all the problems. Sometimes the
architecture is perfectly right but a design or even implementation decision
leads to problems.
But using
an architecture method to design and evaluate systems should handle most of the
problems that can affect the system’s structures. The architect focuses on system
qualities, not functions. Stakeholders define the qualities that are most
important to a system and the architect is responsible for ensuring that they
are met and identifying risks that they are not met. In addition to building a
system from the ground up to meet those qualities, by evaluating an
architecture design with a method such as the ATAM the
architect looks at the system with a “magnifying glass” that allows him to
detect sensitivity points (elements that are sensitive to a certain quality),
trade-off points (elements that are sensitive to multiple qualities in
contradicting ways), risks and non-risks. In summary in the scenario below, the
manager should probably not be making decisions on the backup strategy but he
should also not rely blindly on the developer’s preference because the
developer probably doesn’t have the complete picture to decide what the best
choice is. Instead an architect should be analysing possible solutions
(competing architectures), identifying risks and recommending the way forward,
based on the most important system qualities for the stakeholders.
I was reading a note recently from a DBA
working at a software company. Their management wanted to ensure clients had a
simple backup solution and were leaning towards Windows OS backup instead of
SQL Server backups. They were planning on running databases in simple mode
instead of taking transaction log backups, which were seen as too complex.
While this can work, I'm not sure this is the type of discussion that should
even come up.
Management should be concerned with the higher
level goals. Clients need a simple scripted backup. Period. The implementation
of that isn't something that management should be discussing with developers.
This is the perfect example of where the software development goes off the
track with micro management. Managers becoming deeply involved in technical
decisions and implementations is a sure way to ensure that less than optimal
decisions are being made.
What should happen? Technical developers should
get the goals of management (a simple backup process for clients, every day).
They should then recommend a solution, but with a minimal of technical details.
Managers should have no idea that transaction log backups are being made or a
part of the process. Developers should write scripts, tools, or processes that
allow an administrator to accomplish a goal in an easy to execute fashion, but
shouldn't need to explain how every detail works to the end user.
Keep it simple and effective. That's a mantra
that's worked well for me throughout my career.
Steve Jones from SQLServerCentral.com
No comments:
Post a Comment
Comments are always welcome. They will be moderated for posts older than 14 days. In that case a delay of a few hours can be expected before publishing.