Wednesday, February 11, 2009

Documenting Software Architecture

Software architecture has been around as a discipline for four decades. The discipline emphasizes on the structure of software systems and getting the structure right. The discipline came into the limelight in the 1990’s when complex, large-sized IT projects started becoming increasingly popular and commonplace. The popularity saw the emergence of various different schools of thought that doctrinated different views towards software architecture and popularized them through their adherence in real world projects. With the growing number of variations and views towards software architectures, IT practitioners, typically, feel the confusion on which school of thought to believe in.

However, the toughest challenge to software architects comes in the form of finding the Holy Grail on how to document a system or application’s software architecture. Documenting software architecture is as much a science as it is an art form. While the science lies in the proper analysis, understanding and the usage of the proper description language to define the software architecture of the system, the art form assumes significance when a clear, crisp, non-redundant depiction is required.

Software architectures require a very crisp and clear documentation to communicate the developing solution to the business and IT stakeholders. Many IT projects have bitten the dust owing to lack of clarity in the documented architecture artefacts. This lack of clarity introduces a gap between the system’s architecture and the downstream design and implementation artefacts – deviation is inevitable.

Software architects find it immensely challenging to determine how to document software architecture in a way that clearly articulates the solution. While over engineering and excessive documentation adds significant delays and associated risks to project delivery, sub optimal documentation results in a serious lack of the developer’s understanding of the solution architecture – which is expected to define the constraints within which the technology should to be leveraged to develop the code.

What if I come up with a book on this topic? Would you read it? What would you like to see covered in the book? Your wishes may be granted - just speak them out for me!

Tuesday, February 03, 2009

SOA Governance - The book is out!



The most awaited book on SOA Governance is finally out. It has been aptly entitled: SOA Governance: Achieving and Sustaining Business and IT Agility.I happen to be an author of the same! We have compiled all our collective field experience, knowledge, wisdom and futuristic thinking on this elusive and hotly debated topic on SOA Governance.
The theme of the book is like this: We go into a company and find out that their SOA and the governance around all SOA intiatives is not working - it is broke and they are begging the question on how to fix it in order to reap the true benefits of SOA.
Through a near-real-world case study we take each aspects of this emerging discipline and provide prescriptive guidance on how to institutionalize SOA Governance in an enterprise.

The idea is that, for any SOA initiative, to follow the practical, well illustrated and prescriptive guidelines that is laid out in this book and implement this at your own enterprise or any consulting engagements where you are helping your client/customer out to address SOA Governance as a discipline.

Click here to get to the book on Amazon.