Tuesday, November 13, 2007

Some Architectural Notes:

"Practical Guide to Enterprise Architecture" book published by Prentce Hall has very readable contents. I enjoyed reading it. Here are some highlights

Architecture Is Business-Driven. This is the first and most important habit of an architect. All architectural undertakings should be done for the sole reason of solving business problems. Architecture planning is a continuous process that requires full alignment with business goals.

Communication Is King. Enterprise architecture must be communicated to all parties across all IT organizations and lines of business on an ongoing basis. This should include strategy, goals, and objectives. Its purpose is to increase awareness throughout an enterprise. It must also include a statement of shared values that are endorsed and supported by the executive team and incorporated into the IT governance model.

Unification Is Queen. For enterprise architecture to succeed, it must be unified across the enterprise. Success and failure of all forms of architecture depend upon the joint efforts of all business and IT areas, their support of the architecture, and consistent implementation.

The Frog Is a Prince. Support from the executive team is essential for the practice of architecture, but a successful architecture starts almost at a grass-roots level by seeking support from line managers and their direct reports where the sell is the hardest. Getting buy-in from the troops (Seek first to understand, then be understood) will shield the architecture from passive resistance.

K.I.S.S.: Keep Infrastructure Simple. Information technology assets and the elimination of the endless combinations of platforms that use disparate technologies are the main inhibitors of change and result in an inflexible architecture. A goal of sound enterprise architecture is the destruction of incompatible technologies. If infrastructure is kept simple and consistent, enterprise architecture can leverage existing skill sets, training, support, and services in a cost-effective and agile manner.

Agility Is Key. Sometimes the best solution for a particular business problem requires adoption of a technology and/or approaches that are not mainstream. Agile enterprise architecture will allow the modification of standards to support business requirements, and it will seek out alternate ways to integrate the technology with the current architectural model.
Crawl Before You Walk. Expectations should be managed. The best architecture for an enterprise is one that evolves versus one that is created. Each iteration of the architecture should build upon previous versions and provide an incremental improvement to the organization. Enterprise architecture should also focus initial efforts on near-term opportunities—what is within reach—that can provide immediate business benefit. Small but quick wins will help win allies from both the business and technology areas and will best demonstrate the value of agile enterprise architecture.









It's very important to capture & communicate business/technology drivers well in succinct manner to all the stake holders.Defining architecture satisfying all the stake holder is a very difficult task. Un-informed stake holders will have unrealistic architecture goals. CEO expects application to scale for decades, Manager wants no duplication efffort at any cost & expect that to come completely from architecture, Developers exepects libraries to ease out their coding & Designers expect check lists.


All the stake holders are correct in their own way on the expectation from architecture, but unfortunately Architecture cannot accomplish all the individual requierements & it's important to set the expectation clearly.

Architecture -> Is About Making Technology choices. In my openion this is the most important feature that will have huge impact on any projects. Application maintainence, Deveoper availability should be given as much importance as techincal excellence of the tools that we choose.
Architecture -> Is About understanding the context. All patterns/anti patterns work with aparticular context. If we miss out this context the patterns/anti pattern knowledge can have adverse impact on our judgements.
Architecture -> Is About understanding of problem space & strong connection with business. Respecting the domain experts & their openion is very important here.
Architecture -> Is not just about Reusable artifacts but flexible artifacts. There will be always better ways for implementiion techniques as time progresses. So "re-use" is overloaded word. So I guess flexibility is more important thatn reuse. Interfaces & Dependency Injection (Spring is excellent in serving this pupose & latest version gets you out of XML hell as well :-)) is more important as they give the power of changing the implementation with better means over the time without much pain.
Architecture -> Is about understanding varying scalability requirements, Every one don't require eBay or Amezon kind of requirements. I have personally executed 3 eBay projects as a lead & the rules of the game is totally different for those kind of applications.
Architecture -> Is About breaking rules.eBay doesn't rely on transactions. The data is heavily de-normalized, Most of the processing happens at the application tier. The asynchronous channels are heavily used. ThreadLocal's are used heavily. Scratch DB is preferred way to store the session data. Scaling happens @ the web-tier & EJB's doesn't even qualify as contenders & the XSL templates rule the presentation layer.These rules are definitely not suited all kinds of applications. It was very difficult for me to come out of hang-over of eBay code base.

Architecture -> Is about understanding the Return On Investment & ability to predict the future with political, local & legal aspects in the mind. Documenting patterns & anti-patterns in these areas will be invaluable as experience/historical knowledge holds the key.

Identifying the need of different stake folders & making sure that architecture artifact look relevant to all stake holders is important.So it is better to write different documents focusing on different stakeholders.It is important to keep the theme same in all artifacts. For Example,"System Architecture" document should capture the over-all technical decisions that were made along with explaining the rational & tried alternatives. This document should act as technical design review check list. It's important document non-functional or operational requirements as clearly as possible. Architecture goals and means (usually debating 2-3 options for achieving the same).Integration of various application modules (critical ones).
For any web based applications screens plays very important role & they capture the requirements in best manner. This exercise ideally should be part of requirements definition & this "System architecture" definition process should begin sometime during the middle of requirement definition. Unfortunately it's a tedious task define the screens manually& as of now there is no credible way to convert HTML directly into production by few tweaks (Frameworks like Tapestry & Wicket web frameworks certainly makes better compare to other approaches).
"Application Architecture" Should capture the different technical layers & their components. It also should capture the over-all application modules & their relationships. Integration is the most painful aspect development as it not only involves code integration it also requires to people also communicate & integrate. More emphasis should be given in declaring the interfaces & handshaking mechanisms between the teams & modules.

Conclusion:
Software Architecture is very challenging, I guess aspiring Architects need to focus get in touch with real developers & do active coding rather than relying on marketing literature available in Internet. The best brains sitting in ivory tower developing specification (Martin Fowler calls them Harvesting frameworks) really doesn't add much value compared to specification/frameworks that comes out as by-product of developing real time applications like Spring, Rails. (Non Harvesting frameworks). Unless Software Architects stop forming their opinions based marketing literature and blogs, they will be forced to be called as "White Elephants" of software industry.
Bookmark and Share