Next steps with EFx

A little about the history...

At present EFx (Enterprise Framework) is in a state of transition from the Everett world (.NET Framework 1.1) to (.NET Framework 2.0). Although quite a separate issue from the base framework, EFx is also migrating to the new diagramming and code generation tools of Visual Studio 2005. The vision here is to provide Guidance Automation and Diagramming to the framework to enable developers to build components on the framework, without having to understand the complexities of the underlying classes and to be frank, to save heaps of time in rote coding of the subsystems.

A subsystem is simply a concept, an association of vertical slices of functionality (feature sets if you like) that split the service or application into logical categories. For example, an e-procurement system may have one subsystem for 'purchasing' and one for 'customer management'. A subsystem simply equates to components in a number of layers: a layer containing a any number of web service classes, a layer containing any number of business logic components, a layer containing any number of data access and/or service agent components and a number of auxillary support layers/components (resources/commonality/entities etc). For the developer then, the experience of creating a subsystem requires them to create up to 7 separate projects in a single solution. If you consider most enterprise services may contain a hand full of subsystems, that's a lot of projects to code up. [Of course the benefits (too many to list here) of all these components far outweighs the effort required to simply create a bunch of projects.]

Today, developers using EFx have to follow manual guidelines on how to add these projects in each layer to their framework solution. Although its very straight forward to create the subsystems, it is fairly arduous and prone to manual errors. The work is fairly rote, and this is the the single reason we have not been able to release the framework as a single installation package that developers could pick up and run with right away. (The risk of butchering the architecture and structure by taking shortcuts is too high). The key piece we were missing were templates and wizards to do this for the developers.

Initially, (back in mid-2004) the thinking was that we could do this using Enterprise Templates. [I should explain at this point that as an MS Services Consultant, we have to deal with technologies our customers have and can use in the field at the present time. Of course, Whitehorse was on the horizon, but that's was no use to our customers at the time]. So, after a little delving into this promising technology (Ent. Templates), we ended up with nothing useful. It was simply too hard to get started and deliver anything usable for us.

Developing with the framework itself requires a very basic understanding of layered .NET architectures and the C# language and relies on solid understanding and appreciation of abstraction and encapsulation. Writing subsystems follows a simple pattern that most developers understand easily enough. The beauty of programming on the framework was that you rarely needed to leave its namespace to get anything done. The framework makes extensive use of the Application Blocks (now Enterprise Library) and provides addition features which make the standard tasks very simple, i.e. Validation, Authorisation. The framework also ships with a sample subsystem that showcases most of the common tasks developers code by hand in a solution.

However, we found with most developers using a structured framework, that it took sometime for them to get to grips with how it hung together. In the field (customers & partners), we find that most developers simply are not used to implementing layered architectures, so keeping them from breaking the contract at each layer was the hardest part. (I have lots of funny examples here). Of course, they were initially required to understand the available services and support libraries in the framework, and so it took some time to become familiar with it. We would have to deliver training courses on it and a great deal of education on .NET practices and patterns. We wanted to address this issue, and therefore increase the uptake of the framework, so we decided to take some steps to re-birth the framework and give it a new and more appealing developer experience and easy feel to it.

One of the first steps we took was contacting the patterns & practices group to see if they could help us with expanding the framework and bring it to the masses. Unfortunately, due to some bad timing and probably the wrong contact person at the time, this process was seriously delayed. Anyhow, fortunately much later, after getting the run-around a little, we found the right person around the same time some new key offerings were in the pipeline (GAT especially). With Ent.Lib, GAT, .NET 2.0, VS2005, DSL, Indigo and other factors looming upon us, it was time to make some significant upgrades to the framework. The idea being that with p&p's help, under their wing so to speak, we could make these upgrades to the technology and package the framework and tools as a single package that developers could download and get started with immediately. The vision, would then be that creating the subsystems and defining the interaction between the layers would be a customisable visual experience rather than a hand coded experience.

At about that time (and not so long ago in fact). We re-discovered the DSL toolkit. Earlier, we had briefly looked at DSL and dismissed it as not applicable to our problem right now (in hindsight, of course, totally of the mark) at that time we were convinced GAT alone would solve the immediate issues. However clearly now, a synergy between these two technologies is quite obviously the way forward.

So where are we now?

At present the p&p is busy shipping Ent.Lib 2.0. VS 2005 is out now, DSL, GAT is soon releasing, Indigo got renamed (I must have missed that) WWF came out of nowhere and we have a bunch of other new compelling technologies to leverage. Of course Software Factories (I feel unclean getting on that bandwagon) is now the trendy topic today, which is right on-time for the framework, because people (customers/partners) might start seriously considering a framework in mainstream development projects in the field. This would make my job and my other consultant brothers cry a sign of relief, that we don't have to do so many firefighting/troubleshooting/eleventh-hour rescue engagements to try and recover failed enterprise development projects.

You have to remember that while a lot of us are fighting here at the bleeding edge, there are normal developers working out there who are oblivious to all this, in fact I recently on one of my accounts the lead developer (con)fessed up that he had no idea what SOA was or even that WS-standards existed! This was a lead developer writing real code for real customers. Of course, this is not really funny, you have to understand and sympathise with these guys, they simply don't have the time to go rooting around all the new 'cool' stuff, they are focused on the here and now and struggling with the current platform to deliver a solution on-time to a customer, and this maybe after lots of overtime and over the course of a year long development project which is already over-schedule and budget. Of course, I get to see a great deal of this in my work, the reason these guys are so busy and why projects are failing after so long periods is the sole reason that Enterprise Framework was created, that is, the problem it is destined to solve I mean [:)]. (I'll post another article why these projects are failing (the root causes) and why these developers are overstretched).

So, at present we are upgrading and building a new face for Enterprise Framework. Currently we are on Ent.Lib 1.1, and plans are in progress to build a new DSL with GAT recipes to model the entire service layers. We also plan to leverage WCF (Indigo, thanks Ed), WWF and WPF and a bunch of other emerging stuff. We have along road ahead, and fortunately with the LOB Application Toolkit on the cards in p&p I am hoping we will have an offering second to none in the market place some time next year.

I shall be discussing the progress of EFx and our experiences with DSL and GAT in the near future.

Skip to main content