Architecture... Is it code, or is it data?

Some dev folks are all about the data.  Others are all about the code.  Somehow, we build and improve systems that combine them. I work with many teams, so I get an interesting view.

One team that I work with has a fairly weak data modeling practice. The number of data models on the wall is pretty small.  This is a team that works the code.  When I talk to folks about architecture, most of the folks listen for code.  In this team, new data requirements tend to ripple through the systems.  On the other hand, reuse of code is everywhere and their libraries are sweet.  They cope with their data by creating as few databases as they can.  Data integration isn't a problem when you have only a handful of data sources.

Another team, that I deal with on occasion, is all about the data.  Everything starts with a professional, clean, concise data model.  Databases are everywhere... dozens of them.  That team will then partition the components based on how they access and use the data, not on what the system needs to actually do, which leads to its own set of problems.  Reusing anything they write is nearly impossible.  Every business rule requires system-specific code to pull it out of a database and use it. Their systems have been designed by allowing the business to partition them.  In other words, the business basically decides which system should host a feature, even if it makes no sense from an application or reuse standpoint.

Still another team I work with is all about the products.  They care more about how to squeeze every feature they can out of the technology they currently have than anyone can imagine.  In Microsoft, we get free access to all our products.  We also get access to products under development, which is risky sometimes.  This group manages (somehow) to pick off nearly every new technology and sign right up for implementing it.  Functionality is a function of what you have in the product stack, not what you need for the business.  While their customers have grown used to 'making do,' the relationship between business and IT is based on control, mistrust, and fear, not collaboration and common goals.  Data elements are managed in the structures they have, but they are nearly never integrated.  Reuse is a fantasy, propogated by the few and ignored by the rest.

Architecture is the binding force that can break each of these teams free.  We need the best of each world. 

We need strong data models to decide not only 'what' widgets goes in a system, but 'how' we will control, manage, and distribute widgets through our infrastructure.  We need seperation of concerns at the database level, to keep complexity low and allow for reuse.  We need excellence in data element identity, so that any application can find the 'widget' in the data environment, regardless of what application created it.  We need excellence in data schema, so that everyone has a consistent way to interpret the information on a widget without having to dig rules out of the source system.   

We also need strong application models to decide what capabilities are 'local' to a widget, and what capabilities are 'meta' or require the coordination of multiple widgets.  We need to be able to scale the functionality without scaling the database.  We need to be able to encapsulate business rules in small, easily found, and easily changed modules that can be reused with near-abandon wherever they are called for.  We need to be able to produce, quickly, a completely new application from existing run-time components without generating a complete regression test against the infrastructure.  We need to insure that we limit the number of 'points of failure' so that weaknesses in hardware, networking, and databases can be overcome to provide a consistent and stable experience. 

We need to develop and maintain a deep and thorough understanding of the technology base.  The products must be selected correctly and carefully, and used to their best extent.  The highest of standards must be maintained in privacy, security, and management.  The networks must work.  The data storage systems must be reliable.  From a development standpoint, the infrastructure is the fundamental source of both power and constraint. 

When writing systems, Architecture is all three.

So if you are going to stand up an architecture team, include real strength in each.  Get men and women who care, and who are not afraid to argue with you, bargain with you, and brainstorm with you about the Application Structure, the Data Model, and the Technical Infrastructure.  Build a team.  Then build excellence.