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.

Other patterns are less part of the software development process, than they are part of the software delivery process. Source or Version control is a pattern that allows us to recognize multiple versions of a particular code base and recover them without guess work. Build framework is a pattern that reduces the manual effort required to build a deployable code base. Testing framework is a pattern that allows us to automate routine tests against a code base to ensure a higher initial build quality.

I know that when I start talking about patterns, most of you will immediately begin to think about design patterns, like those famously promoted by the “Gang of Four”. But what I am really talking about is implementation behaviors that an organization can adopt.

Development “Stack” is a pattern that has emerged over the last 20 years. In earlier days, the stack was quite flat, having very few layers, with most of the code comprising a software system running on the same physical machine, and being written in the same language. Today, development stacks are quite deep, having several physical layers, and even more logical layers, each layer potentially implemented in a different language paradigm, or multiple language paradigms. Twenty years ago, I was developing programs in MUMPS, running on distributed or mainframe platforms, and all coding that was needed was written in that language. Now I write SQL, C#, HTML, CSS, Javascript all for the same application.

The notion of a development stack, has become a primary concern for organizations that engage in application development, as with current web user interface strategy, several languages are bound together into a single layer strategy including perhaps HTML5, CSS3, Javascript, and whatever you run on the server (PHP, C#, Java) to complete your application. A middle “tier” may have yet more languages, and a storage or data tier may have more languages still.

The complexity of development environments, requires an investment in patterns so that tools can be selected that increase the effectiveness and efficiency of software development teams. As an executive, you must recognize that this investment will happen either in the large or in the small, meaning that either the organization figures it out for the teams, or the teams figure it out for themselves, or sometimes both. You may select the “enterprise” patterns (meaning that you define the “supported” architecture or development stack) if you don’t also invest in practices at the enterprise level, each team will need to independently invest in practices. When this independent investment happens, results (cost, quality) can vary dramatically between teams, and opportunity for sharing practices between teams is greatly diminished. In fact, if the enterprise chooses not to invest in practices, it can create a culture that even devalues the pattern, over time.

Practices also exist around non-code aspects of the development process. Requirements engineering, user interface/experience, visual design, product/project management and Quality Assurance all support patterns and practices (with tools) can be established around them.

Practices create Bodies of Knowledge that can be shared and used by the entire organization. Investment in practices can create centers of excellence (or centers of expertise) that can add know how and know why to an organization. Practices care as much about the practitioner and the results as they do about the pattern that they are supporting.   Practices care about getting value from the pattern, rather than implementing the pattern purely, so they rarely appear as “gatekeepers” or “pattern police”.  Practices encourage developers to become practitioners by making it easy for them to get value out of the pattern, and by treating the practitioners like customers. Practices select and implement tooling, staying current as tool versions are released, making it easy for practitioners to take advantage of new version capabilities.

Organizations can invest in practices in the following distinct ways:

1) Hire talent to initiate and lead practices

Lets face it, for new things, you probably don’t already have the expertise in house to start a new practice. Even if you do, if you don’t create a new position to do that, you are taking one of your best people and having her do practice leadership in their “spare time”. If it is important, staff it. Otherwise don’t waste your time. If you don’t have a good idea what value a practice can bring, stop and figure that out first. Building practices for the sake of practices is not valuable. Hire the person who either has experience bringing this value, or is at least passionate about this value.

2) Hold the practice leads accountable for results

Practices are supposed to make IT better. If they aren’t making it easier to implement the pattern they are supporting, then they are not valuable. Practice leads should be accountable to demonstrate value, whether by showing case studies or by demoing examples. If you build it and they don’t come, it probably means that what you built is flushable. Practices should be focused on making life better for practitioners. They are the customer. Customer satisfaction is a reasonable metric. Practices that mean more manual labor, more confusion, more CWT meetings or more obstacles to getting things done are not helpful. Practitioners are going to revolt, and revert to their former, more familiar practices if you don’t give them a good reason for adopting new ones. … And no, not getting fired is not a good reason to adopt a new practice that sucks worse than the old one.

3) Fund tooling, training, and practice leadership on an ongoing basis.

On the way to reducing manual labor, confusion, and obstacles – implementing tooling and making training available are good starts. Staffing practice leadership so that they have time to consult with practitioners to help solve real issues, sharing their expertise is also important. Making learning materials and reference implementations available to practitioners is valuable. If you act like you want to get the most for your investment (in the pattern), you will make it easy for practitioners to get value out of it. Staying current on versions of tooling, and giving practitioners some control and optionality in the way they implement tooling is important.

4) Incent practitioners (and their managers) to participate in practice engineering and leadership activities.

If you want practitioners to bring value to your practices, you need to create space in their schedule for them to participate. If you want to build a sense of ownership (of the practice) among practitioners, they need to be active in defining, leading, and building the practice. Assuming that you already did 1,2 and 3 above, so there is expertise for them to learn from, and value for them to get from the practice. You do this by recognizing that developers don’t just write code all day. They think about how to make things better, easier, faster, etc. One challenge is that their own manager can’t release them to work on practices because they are focusing on their customers. Additionally, if the Practices don’t have funding (so a manager is just giving up productivity of their staff, but not getting much back) then you won’t get much action. Last, if you just hire people who work on practices, but not on real world projects, they lack the real world perspective about meeting actual customer needs, those (practitioners) who have that perspective are disincented from participating. This ultimately creates an ownership gap between the practice leads and the practitioners that can cause the practice to lose value over time.

No Comments

Post a Comment