I recently met a friend and fellow software engineer to discuss his current project. We met earlier this year during my .NET Code Camp presentation. I appreciate his candid feedback and suggestions for future articles, since he is a very talented developer and fanatical baseball fan. Although I really enjoy baseball, I am more of a seasonal fan in October. He is also an advocate of the same software design principles and supporting design patterns outlined during the presentation, which I also featured in “How to design and build better software for tomorrow?” multi-part series.

The Project

The project entailed building three major back-office applications, so he assembled a development team for each application. The teams were instructed to follow the software design principles, which they all agreed were important. After several weeks, he was surprised that each team presented such different solutions. The data access layer choices were NHibernate, Linq2Sql and Entity Framework. Although all teams built web solutions, two teams selected Model-View-Controller (MVC) and the third team Model-View-Presenter (MVP). The teams also selected different Inversion of Control (IoC) frameworks, which included Spring.NET and Microsoft Unity. They also followed different validation and exception handling strategies. After he summarized the current status, he expressed his disappointment and frustration. He was obviously directing some of the blame at me. I apologized and sympathized with his frustration. After a brief baseball playoffs and politics conversation, I suggested we work together to rectify the current situation and develop a plan to get the projects back on track. He recognized the long-term impact would be detrimental to the organization, since they would be forced to maintain so many competing technologies, tools and implementations.

I am not surprised that three teams delivered three different solutions. The core principles provide guidance and promote well- designed software, which all three products exhibited. They encourage a design that meets the objectives of the organization and project, but not tightly coupled to any implementation. Change is expected. The ”How to design and build better software for tomorrow?” multi-part series demonstrated a variety of presentation, business and data access layer implementations. The same principles and design patterns were applied to console applications, WinForms and MVC. We developed concrete data access implementations using pure ADO.NET and LINQ. The core software design principles and patterns are also platform independent, so we built working .NET and Java applications.

After this explanation, he better understood the objective of the software design principles and patterns. We agreed all teams were successful and accomplished the objectives. What went wrong? How do we fix it?

Enterprise Architecture

The enterprise architecture is an organization-wide framework containing a collection of collaborating modules to support the organization’s needs, which is the foundation for a unified platform. This requires establishing the common infrastructure or framework promoting the same core software design principles and design patterns. I would also include the supporting processes.

The logical approach is building a common framework before launching the development of the domain-level modules, but we now have three working applications and no enterprise architecture. After reviewing the three applications, we noticed the teams built similar interfaces and abstract classes. They also share many common services and concrete implementations. These are all common framework candidates, but we were still faced with many decisions as the enterprise evolves. In the end, we decided to apply basic project management techniques and invite the three teams to participate in the sessions. We referred to the three applications as “prototypes” and discussed the technical merits of each including risk, cost and schedule assessments. The teams prepared demonstrations and discussed the technical design. Although the teams initially lobbied for their design, the project management techniques reduced the probability of a biased decision.

The following is a summary of the major decisions and foundation for building the framework.

  • Presentation/User Interface - MVC3 and Razor using view models
  • Business - service objects acting as the entry points coordinating the exchanges between presentation, other service objects and the data access layers
  • Domain – a rich domain-driven design (DDD) supporting enterprise validation
  • Data Access – persistence using NHibernate to SQL Server
  • IoC – Spring.NET

After a few weeks, the enterprise team started building the common framework based on the agreed technical design. Once the framework is complete, the team will refactor the three applications to integrate the common framework. Since the team followed the core software design principles and design patterns, this task will require much less work. The Dependency Injection (DI) pattern and IoC will simplify this process, so the team can focus on building the domain modules to satisfy the needs of the organization. The project schedule was pushed slightly to the right resulting in a delay, but all is not lost. The team is confident the common framework and wealth of reusable components will enable them to accelerate the schedule and deliver the products on time. They also agree the quality will be much improved. Maybe you did not notice, but I no longer refer to them as teams. The experience not only produced a unified enterprise framework, but they are now a unified team.

In the majority of my engagements, we always plan and build a common framework. If you do not have a dedicated team to maintain the common framework then appoint members from all project teams to participate. In both cases, the enterprise team should act as the change control board (CCB) to approve or deny change requests. It is critical to ensure changes do not break existing features or modules, so following the best testing practices is essential.

When the team extended an invitation to participate in this process, I could not decline the offer. They also agreed to allow me to blog about the experience and share with the community. So…I plan to chronicle the journey and decisions along the way including plenty of code examples. Please visit again soon…

Building Enterprise Frameworks – Data and Domain

Building Enterprise Frameworks – Testing and Mock Objects