As a solutions architect, I am often working on projects at various
levels of management. Depending on the level I am operating at, I will
make use of, incorporate to, or help design frameworks, principles,
patterns and practices. Often, there seems to be a lot of confusion
about exactly what the purpose of these constructs are.
Let's start with Principles. I think that simplicable has a really good definition of what principles are. It states that principles are enduring rules and guidelines.
If you think about it, upper management uses principles all the time to help motivate staff and ensure that people are pulling in the same direction. In management, these appear as mission statements, and corporate charters.
The goal of principles, in my mind, is to set the overall vision. Akin to a core belief, principles help govern the frameworks, patterns, and practices that are used in an organization. Further, principles give the nuance that guides how the other constructs are used in an organization.
Frameworks are essentially a set of principles and practices rolled together. While it is true that the principles and practices may not be called out explicitly, the role of a framework is to provide an overview of a particular approach to achieve a specific objective. It serves as a guide, and can be modified as required.
It is always important to remember that a framework requires implementation. The implementation is not simply taking all the guidelines inside the framework and implementing, however. It is the act of applying the framework, along with the principles of the organization, and determining the parts to modify and the parts to keep the same.
A framework that is implemented with no regard for the business context that it sits in can serve as a huge roadblock for future growth of that organization. Alignment is crucial.
There has been a lot of talk these days about practices. At least for me anyways. I can't count the number of times that I have walked into an engagement where the client has asked for best practices. If you have studied the cynefin framework at all, you'll have learned that best practices only exist when the task at hand is obvious or simple.
In any event, practices used in an organization, or for a project, will be derived from the framework being used, and be nuanced by the principles in play. ITIL, for example, provides and leads to many practices. However, if your organizations principles are that it is better to deliver something half-done then wait for something great, you'll modify the corresponding practices in use to comply.
Many people like practices, because they are the concrete implementation of the principles. Think of it as answering the "how" question, whereas principles answer the "why" question. Practices are great, but be careful of expecting a particular practice to define how to deal with every situation.
Patterns, on the other hand, can best be defined as a general, reusable solution to a commonly occurring problem. If you think about it, patterns could be seen as a construct within a framework, and could prescribe practices to follow given a particular situation. I like to think of patterns as advice. Not all of it fits my situation, some of it may require modification, and sometimes I can piece together advise from different people to form on my own solution.
From an SA perspective, I find it very important to capture principles and frameworks as the start of my projects. Getting guidance in those areas from the client help shape my solution, and provides some assurance that I will be focusing on the aspects that are important to the client.
Let's start with Principles. I think that simplicable has a really good definition of what principles are. It states that principles are enduring rules and guidelines.
If you think about it, upper management uses principles all the time to help motivate staff and ensure that people are pulling in the same direction. In management, these appear as mission statements, and corporate charters.
The goal of principles, in my mind, is to set the overall vision. Akin to a core belief, principles help govern the frameworks, patterns, and practices that are used in an organization. Further, principles give the nuance that guides how the other constructs are used in an organization.
Frameworks are essentially a set of principles and practices rolled together. While it is true that the principles and practices may not be called out explicitly, the role of a framework is to provide an overview of a particular approach to achieve a specific objective. It serves as a guide, and can be modified as required.
It is always important to remember that a framework requires implementation. The implementation is not simply taking all the guidelines inside the framework and implementing, however. It is the act of applying the framework, along with the principles of the organization, and determining the parts to modify and the parts to keep the same.
A framework that is implemented with no regard for the business context that it sits in can serve as a huge roadblock for future growth of that organization. Alignment is crucial.
There has been a lot of talk these days about practices. At least for me anyways. I can't count the number of times that I have walked into an engagement where the client has asked for best practices. If you have studied the cynefin framework at all, you'll have learned that best practices only exist when the task at hand is obvious or simple.
In any event, practices used in an organization, or for a project, will be derived from the framework being used, and be nuanced by the principles in play. ITIL, for example, provides and leads to many practices. However, if your organizations principles are that it is better to deliver something half-done then wait for something great, you'll modify the corresponding practices in use to comply.
Many people like practices, because they are the concrete implementation of the principles. Think of it as answering the "how" question, whereas principles answer the "why" question. Practices are great, but be careful of expecting a particular practice to define how to deal with every situation.
Patterns, on the other hand, can best be defined as a general, reusable solution to a commonly occurring problem. If you think about it, patterns could be seen as a construct within a framework, and could prescribe practices to follow given a particular situation. I like to think of patterns as advice. Not all of it fits my situation, some of it may require modification, and sometimes I can piece together advise from different people to form on my own solution.
From an SA perspective, I find it very important to capture principles and frameworks as the start of my projects. Getting guidance in those areas from the client help shape my solution, and provides some assurance that I will be focusing on the aspects that are important to the client.
