Enterprise architects are responsible for providing simple, effective, enterprise worthy, domain components to the application developers.  So what makes a good domain component?

  • It must provide quantifiable BUSINESS value over time.  This may be the result of lowering the time and related cost required to build applications implementing the component.  It may be the result of reduced helpdesk costs by standardizing error messages. It may even be the result of improved utilization across development teams by reducing the learning curve associated with each application startup.  Regardless of exactly how the value is achieved it must be clear how the business will be impacted and what changes to process are required BEFORE you build it.
  • It must be broadly applicable across applications in the enterprise portfolio.  In most organizations broadly could be interpreted to mean as few as 3 or as many as all applications. Broadly applicable components tend to make themselves available as directly callable, inheritable, or implement-able classes.
  • It must be stable, or at least built in such a way as to prevent future changes from damaging the applications that depend on it.  Tool selection has a tremendous impact on this one.  Using .Net, we can leverage things like side-by-side deployment, interface classes, and loosely-coupled events.  Each component design needs to meet the minimum requirements for an enterprise worthy component.

Compare that to what makes a good plumbing component;

  • Provides system level services (logging, transaction management, etc…) to any calling component
  • Capable of providing their services in more than one business domain with little or no modification,
  • Don’t affect the facts being acted upon by domain components.  This is an odd but consistent pattern.  Data access components don’t impact the transaction they enable it.  Logging components write what is passed to them without change. 

As an industry we are just starting to create plumbing components for broad consumption. Microsoft’s Patterns and Practices site (http://www.microsoft.com/resources/practices/code.mspx) has several well thought out plumbing components.  These are perfect fodder to kick-start the lowest level of enterprise development.  Personally, I have great hope that we, as an industry, will begin to implement the plumbing behind a higher level of abstraction targeting specific Domains.  Consider a school system.  One would think an enterprise approach would provide components for Students, Faculty, classes, facilities, and schedules.  We could logically extend this to create a layer between the domain components and the plumbing which might include, time, location, person, and organization, with a structure something like the illustration below.


Application developers could use these domain parts, without knowledge of or any need to muck with the underlying plumbing.  They need only add some application specific parts, stir in the needed logic, and test well at 400 degrees for 30 minutes … and poof, one enterprise compliant application. 

I don’t mean to over simplify a truly complex task.  Creating an API is high art.  Extending that API to object models makes it staggeringly complex for those who create them.  However, this is our mountain to climb.  This is the hard work that we as enterprise developers need to suffer so that all (enterprise, developers, customers, and end-users) may have their cake … robust enterprise class products… and eat it too … quick, less expensive, less complex application development.