Thoughts on Technology Domains

So I have a plan: I want to start categorizing that huge pile of technologies in my company. Where do I start? How should I partition it? What has been done before me? Are there best practices already in the field of technology architecture management?

Separating the vast field of technologies in "buckets" helps to do the following:

• Apply ownership and responsibilities to groups of technologies
• Provide a governance framework based on these buckets, to foster standardization, reuse and provide the necessary processes to handle exceptions
  
• Provide detailed "cost per topic" views (e.g. database technology costs, application server costs, etc.)
  
• Create the basis for technology lifecycle management (e.g. decommissioning/phasing out of products, moving to new technologies, etc.)

The following domains are a "safe bet" to me, i.e. you will most probably not get a huge push back on them:

• Base Infrastructure: Server and workplace hardware and operating systems, network components and services
  
• Database: DBMS, Document Management Sytems
• Middleware: Application servers, workflow and messaging infrastructure
• Workplace: Laptop or desktop platform including hardware, operating system(s), and tools, with a focus on business users
• Application and Service: Buy and inhouse developed applications including internal and external services, including all around integration and software development
  

The following domains are optional, depending on structure and size of your company:

• Information Exchange: Most companies of today need a well managed platform to copy data between the applications.
• Business Process & Workflow: Platforms and tools to provide process and workflow management features to either directly to users or to the applications
• Information Exploitation: Platforms and tools to identify added value from our own data. Often, this is integrated in the Database domain

Domains that apply to all of the domains mentioned above (i.e. orthogonal to them) are:

• Security: Mechanisms to protect and properly access applications, services and their data
• Systems Management: Domain crossing tools and platforms to manage Swiss Re's runtime components

From what I've seen, such a structure os widely accepted in the market today. Apply this list to your technology portfolio and to your organizational setup.

Strategies for such domain structure differ between companies. Some might need a rigorous reduction to a small number of products, others might need a larger diversification to make sense to business. And here's the top down approach again - it is finally a call from business to define which domains are important to a company and how those domains need to be organized and managed.