Picking up the pieces...

Thank you to Karen Lopez for finding and praising a blog post by Anith Sen.  He writes about database design errors, Karen disagrees with some of Anith's conclusions in her blog which goes to illustrate that design is a mix of art and science and that even experienced practitioners will disagree over details.  

Anith observes that "an application can trespass on the field of data management" and that developers sometimes "treat the database as being a mere component of the ‘application domain’".  Particular skills and experience are required to manage data and to create and maintain databases.  Data management differs on at least two levels:

1. At the programming level, being able to write an SQL statement is not the same being able to design a database.  The set based thinking required to develop design a database effectively is very different to the procedural thinking required by most programming languages.
2. Databases have a different life-cycle to applications and they are often shared between applications.

In my previous blog, Vive la différence, I stated that we do not train people in design.  I think this is a illustration of this point.  We often don't teach an understanding of data management and its approaches.  This results in designers and architects having a poor understanding of the role of databases in the application landscape and people like Anith having to pick up the pieces.

Vive la différence...

Tom Graves has summarised the differing roles of architects and designers in his blog What’s the difference between architecture and design?.  It is an ongoing irritation to me that the two are confused.  This not only devalues both disciplines, it has serious and deleterious effect on the quality of solutions delivered.

An architect as Tom states "faces towards strategy, structure and purpose, towards the abstract", the role is about ensuring we do the right thing.  The designer "faces towards implementation and practice, towards the concrete", ensuring we do it right.

In 1990, Mitch Kapor delivered his Software Design Manifesto.  He appealed for "design" to get the recognition it deserved as a critical profession in the creation of software solutions.  I thing we have gone part way there.  We have recognized, even if often misunderstood, the discipline of enterprise architecture.  We recognize, but have little formal method, the act of solution architecture.  But we still do not really recognize or train people in design.  In my opinion, we seem to have gone backwards in training people in the logical technology independent fundamentals of good software design.  Rather, we have encouraged technology obsession and limited the careers of good designers and architects.

For those who don't remember or don't know, Mitch is one of the fathers of the modern computing era, he was a founder of Lotus Development Corporation and the designer of Lotus 1-2-3, the "killer application" which made the personal computer ubiquitous in the business world in the 1980s.

How to write technical documentation...

Jeff Moser has written an excellent article describing how the Advanced Encryption Standard works.  He uses an very accessible paradigm - the cartoon.  He layers the description starting with a simple overview and progressively getting into more and more detail.  Because the story is layered, it is complete at each stage before more detail is added.   The audience has the opportunity to leave when they know enough. 

Building enterprise architecture the right way

Ken Karacsony writes an interesting article about the practical use of business architecture to shape business change correctly and contrasts this with a typical IT driven approach which can fail to address the correct issues.

Enterprise Architecture Pitfalls

Brenda Michelson has put together a good summary of the recent Tweets following Gartner’s recent listing of EA pitfalls. 

The EA community seems to have come to the conclusion that Gartner has stated the obvious.  The Tweets have provided “real” EA pitfalls based on the experience of practitioners.

If you read the blogs of the community of practitioners then you will find not only the pitfalls but the solutions to them.  These solutions have been discovered through the sweat and tears of those who have been there, made the mistakes, and got the scars.

The Twitterverse and Blogosphere has enfranchised the “doers” who previously didn’t have a voice.  But more importantly, the current generation of decision makers and key influencers understand the value of the information that is out there and freely available.

If you read the blogs, you won’t get a neatly package “answer” to your problems.  But you will, after some time and effort, get insight.   You will have to work out for yourself what is relevant and what is not. You will have to work a little harder to get to a plan to take your organization further.  But you will learn, and you may just have a plan that can deliver meaningful results.

The criticism of the identification of EA pitfalls follows very close behind similar criticism by the EA community of Tweeters of “Emergent Architecture”.

The analysts need to demonstrate that they talking to the right people, that they are gathering the right information and finding genuine insights based on the experience of practitioners.  If they can deliver better results quicker and cheaper than doing it yourself then they will have a valuable offering.  The recent Twitter discussions suggest that they are behind the curve.

The analysts must engage and embrace those that do and know.  If they don’t then I suspect any deficiencies in their offerings will continue to be highlighted.