A week ago, I invited the architects forum in Microsoft Israel for the 6th time and this meeting was on the topic of architecture frameworks. Based on the interesting discussions and feedbacks, I got the impression that this was one of the best meetings so far.
Joining the Forum - The architects forum consists of the thought leader architects in Israel and its purpose is to assist the architect community in contents and in better defining the role that they do. If you feel your place is with us, please read the following post on how to join the forum.
What is an architecture framework? There is no single definition of an architecture framework, so I will try to refer to what we meant by this. We referred to a set of generators that can create code, documents etc. The idea behind it is to give a quick start and a set of guidance to help developers develop in an easier environment.
When should an architecture framework be developed? Everyone agreed that a framework makes sense if it will be reused for multiple projects and that the framework should embed the commonalities between the projects. The idea is not to make it too specific because then it might become non-relevant for most of the projects.
The First Session
We started the forum with a session from Yaniv Hakim who is the development manager from eWave. Yaniv introduced a real world architecture framework that they developed called e-Gen. This was a very interesting presentation that showed how far we can go with architecture frameworks. e-Gen provides generators for building ASP.NET applications. e-Gen was upgraded to .NET 3.0 lately and is installed in dozens of enterprise applications. It includes a set of starter kits and code & database generators. It leverages the term of skeletons which is an N - Dimensional Hierarchical ADT for storing context between objects. An application that was generated using e-Gen can be further developed with regular .Net. Feel free to download the presentation from here.
The Second Session
Next, Ohad Israeli and Eyal Vardi who run Experts4D talked about architecture frameworks developed by Microsoft. They talked about the Composite Application Block (CAB) and its younger brother, the Smart Client Software Factory (SCSF). These architecture frameworks are used together to help developers build composite smart clients today. This framework implements so many concepts and patterns that a new vocabulary should be used by its users: MVP, MVC, Blackboard, Use Case Controller, Lifetime Container, Service Locator, Object Builder, Pub/Sub (n on m), Command Patterns and many more... Ohad also revealed an implementation that he released to codeplex that integrates WPF and CAB together. You can download it from here.
This is the place to say that Microsoft has been introducing architecture frameworks for years including Enterprise Library, the new ESB guidance and the different software factories introduced by the Patterns and Practices team.
The Third Session:
The third and last part of the forum meeting was reserved for Memi Lavi, a Microsoft Consulting Services (MCS) architect who presented his own practices from using architecture frameworks. This is what Memi wrote about his session, Architecture Frameworks Usability:
"I’ve found out that there are some basic principles that when not applied to the project, will make the project fail. Those principles are architecture-agnostic as well as technology-agnostic, and they apply to .NET as well as Java.
The main concept is that we, the architects, should always remember that there is an end user for our architecture, which is the developer, and we should give him something he can work with.
The principles are:
1. Select the right architecture for the right task –Don’t try to build the Eiffel tower for a simple data entry system. Remember that the project is not a wish list, and don’t try to apply every buzzword known to humanity just because you can.
2. Measures – Set simple, measurable, targets for the architecture before development start. Define the time needed to develop new forms (or pages, for that matter) using the new architecture. Test the architecture using those targets, and find out whether those targets were accomplished. If not – fix the problems, and try again.
3. Flexibility – No architecture can solve all the problems of the system. It should lay the foundation for 80% of the tasks. More importantly, it shouldn’t interrupt the developer to accomplish the remaining 20%. It should be flexible and extensible enough so the developer won’t have to “by-pass” it in order to complete his tasks.
4. Exceptions – use smart, efficient exception handling. Don’t hide exception information, but don’t spread it all over the screen either.
5. Configuration – Avoid the “Over Configuration” syndrome, when all the business logic resides in external XML files. Use those files for their intended purpose.
6. NIH – Avoid the “Not Invented Here” syndrome. Buy instead of Build.
7. IDE Customization – Whenever possible, customize the IDE to accompany the developer with his routine tasks. GAT / GAX are a good example of that.