IT Patterns and Practices

In my prior post ( ITStrategyInternals ) I explained a little about patterns and practices. Patterns and Practices within IT go hand in hand, in that we have an established solution, and a body of knowledge and expertise around that solution.

I think that we sometimes think that by selecting a tool, we have defined a pattern. So let me say, that patterns are at a higher level of abstraction than a tool. A pattern may require some tooling, but it should not be specific to a tool. The body of expertise around implementing a pattern with/through a specific tool is a practice. So ORACLE DBMS is not a pattern, but a data warehouse may be. Likewise, MQ Series is not a pattern, but a message bus may be. We may have a practice around implementing a message bus using MQ Series, or TIBCO, or Tellurian sockets or Oracle SOA Suite.

Tools are really only valuable, in that they enable the delivery of patterns. Tools can be anything from an integrated development environment (IDE) to a component library to an operating system. Programming languages are not tools, but editors and compilers are. Programming languages are patterns. SQL is not a tool, but MySQL is. SQL is a programming language that is a common part of a relational database pattern. We have come to expect that any tool that enables a relational database pattern implements some version of the SQL programming language.

Those of us who have been in this industry for a few years, realize that the players (tools) change pretty frequently. As a new pattern emerges and is perceived as valuable, it disrupts the market for a while, then the tools supporting the new pattern prosper, and the others diminish and sputter towards irrelevancy.Continue Reading

Chicken and egg

I continually argue with myself about whether tools or process should come

Adding process without tools makes it hard to enforce process rules,
implement consistently, or measure compliance.

Adding tools without clear process definition is also futile, as people
tend to use tools differently, and tools can impose limitations on process
that make later process improvements impossible without replacing tools.

— the balm here is to grow your own tools and process in concert. Build
just enough tool to bootstrap process, then evolve.

This requires the stomach to build tools, and not give up. —