I don't envy the work that Enterprise Architects (EA) do. The closest that they actually get to architecture is describing, often in PowerPoint, a target 'to-be' architecture that will never actually materialize because something will change before it has a chance to. Enterprise Architects are the technical head controllers in the context of Pat Helland's Controllers and Doers blog post. EA's working in the Microsoft stack want a set of technologies that everybody uses, and they do mean everybody, that allows all parts of the organization to talk and share data using the same language. It is this drive that has allowed 'best-practice' of SQL stored procedures, Biztalk, DataSets, SOAP and other technologies to become part of the enterprise landscape and toolkit.
The Doers on the other hand are the developers, tech leads and solution architects that would like to comply as much as possible with the prescribed enterprise architecture but find that it doesn't fit their approaches very well. Your organization's incumbent enterprise architecture is probably not suited to TDD, IOC, DDD, LINQ, MVC, loose coupling, dynamic languages and a whole alphabet soup of acronyms describing the approaches that a certain group of developers find useful and fashionable. So the Doers go off and build stuff that solves their problem and delivers their solution and, quite frankly - bugger the outdated/illogical/restrictive/unusable enterprise architecture that should be followed.
Pat Helland draws the analogy between Controllers and Doers to the American Two-Party system of politics, which is arguably better for all than a Zimbabwean single party style. Similarly, enterprises require both Controllers (Enterprise Architects) and Doers (alt dotters) in order to function. The enterprise architect has a goal of making sure that there is a degree of standardisation in terms of practices and interop; while the alt dotters are pushing the technology and finding innovative ways of delivering systems. Not everybody is happy all of the time and friction does exist, but it seems to work - somewhat.
Enterprise Architecture paints a picture of how the systems within an enterprise should look. By dictating standards it is not expected that all systems will be magically conformant overnight - how can they? When an Enterprise Architecture document is published it is there to influence new developments, purchases and integration efforts. Projects that are currently underway will be excluded and purchases of established products may be given leeway. The idea of Enterprise Architecture is to get the various systems, not at the same place, but pointing in the same direction - similar to the wind on a field of wheat.
The other thing to remember about EA is that the standards pursue a longer-term goal - say five years down the line. It has to because some planning has to be done. But in five years things can change a lot - it's a gazillion Internet years, or dog years or something. Can you imagine what the EA document of the year 2000 would look like, full of COM+, compared to what landed up being implemented in 2005? What about a 2004, .net 1.1 era document - we wouldn't build systems like that now? So it is perfectly reasonable for a 5 year EA document to be updated every two years, even if that means getting rid of the previous author - but at least the systems are pointing in a the same direction. The EA documents of years gone by gave us stored procedures, datasets, xml interop - although maybe not what we would like to be working with now it is not that it was all bad.
The evolution of the EA document is influenced by a number of factors, including the market Gorillas (such as Microsoft) and the Doers within the organization. It is generally understood that the EA document is expected to shift over time, as more information, feedback and practices become available. The Doers in the organization are crucial to that shift and should take pride in their influence on the shift rather than bleating that the shift is not a radical change.
One of the shifts currently taking place is around ORM's (which have been around for more than a decade but have not yet become mainstream). It is significant that we are starting to see a shift in EA towards ORM's - and this is a very big deal. So the Doers went off on their own projects using nHibernate (or some similar ORM) and started getting the attention of Enterprise Architects which started asking their big vendors (such as Microsoft) for some solutions. The Entity Framework (EF) is Microsoft's response to the request from Enterprise Architects for ORM styled frameworks - although it may not be a pure ORM, it is pointing in the right direction. LINQ to SQL, on the other hand, is still something that sits in the domain of the Doers, rather than the Controllers - as evidenced by the support from the community but without support from the enterprise (either your own or Microsoft themselves).
Asking Microsoft to ramp up LINQ to SQL is asking them to position a Doer framework against a Controller framework - in the enterprise. That will simply not fly - Microsoft needs a framework that makes the Controllers buy into it and that framework is the Entity Framework. From an EA point of view, the EF is compelling - not only are developers able to use it's artifacts but they can be re-used across a wide variety of technologies and services; EF is positioned to run RESTful through ADO.NET Data Services, be viewed by SQL Reporting Services and I am sure Biztalk, MOSS and any other MS technology along the way. Since the practice of Enterprise Architecture is largely concerned with data integration, the idea of shared EF objects is compelling indeed. That kind of EA approach and soltuion is not even on the radar of open-source ORM groups such as nHibernate.
A post by Steven Forte references a .NET Data Access trends survey that indicates that 79% of developers use ADO and stored procedures (including Enterprise Library) and 8.5% use LINQ to SQL. That is nearly 80% of production .net apps that are pointed in the wrong direction for the next shift of enterprise architecture. While you can't necessarily ignore the LINQ to SQL and nHibernate groups, they are Doers anyway and will do whatever they damn well please anyway. I for one support EF as an ALT.ernative data access technology choice for the other 80% - if EF is the only option that is bearable for enterprise architects.
So, all the alt.NETters and other Doers in the community, take a round of applause for facilitating the shift in Enterprise Architecture that has been struggling to break through for more than a decade. Move on, go and work on the next shift that is due, leave the Entity Framework in the hands of the Controllers so that as many projects as possible can get to production as soon as possible - and pointing in the right direction.
Simon Munro