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