Lately I have been thinking about what factors are involved in determining a successful road map to success for technology in business. Most of the time I am developing plans for customers and applying my current knowledge of technology to the business context. So far I would like to think that I have been quite successful for myself and my customers in delivering solid technology plans which provide business value when implemented. I have been doing this without a roadmap or a foundational plan. Most of these ideas have come through what I can only decifer as logic and ability to weigh many factors at once.
While reading a book recently called SOA Compass (by Norbert Bieberstein, Sanjay Bose, Marc Fiammante, Keith Jones, Rawn Shah) I found an interesting section on defining “Enterprise Solution Assets” (ESA). The essential elements to defining an ESA were:
- Name – a way to identify and index an ESA into a catalog with a one line statement describing the intent of the asset
- Problem synopsis – describes the problem to be solved by this asset
- Context – describes problem in terms of a real world example in which the asset may be used
- Forces – depicts the architectural decisions and design considerations leading to the solution in this asset
- Solution – the core of the asset which contains a general solution to the problem in the form of technical design documents, model diagrams, and example solution package
- Consequences – the pros and cons of using this ESA as a solution
This may remind you of many other methods for defining design patterns in software development. Here is the listing which Grady Booch posted from his research of ways that patterns are documented. Here is listing from his post:
- AGCS – form, aliases, problem, context, forces, solution, resulting context, rationale, known uses, related patterns, sketch, author, date, references, keywords, example
- Beck – story
- Beck and Johnson – preconditions, problem, constraints, solution
- Buschmann/Schmidt/Kircher – description, example, context, problem, solution, structure, dynamics, implementation, variants, example resolved, known uses, consequences, see also, credits
- Coplien – problem, forces, solution
- Fowler – how it works, when to use it, example
- GoF – name, kind, intent, also known as, motivation, applicability, structure, participants, collaborations, consequences, implementation, sample code, known uses, related patterns
- Grand – synopsis, context, forces, solution, consequences, implementation, code example, related patterns
- Kerievsky – motivation, mechanics, example
- Patternshare – view, role, aspect, summary, context, problem, solution, related patterns, publication, attribution
- PLOP – problem, solution, context, forces
- Pont – context, problem, background, scoluion, hardware resource implications, reliability and safety implications, portability, overall strengths and weaknesses, related patterns and alternative solutions, example, further reading
- Portland – forces, solution, name, part of
- Sane – title, abstract, intent, motivation, solution, trade offs
- Trowbridge – context, problem, forces, solution, approach, design considerations, example, resulting context, benefits, liabilities, testing considerations, security considerations, operational considerations, known uses, related patterns
Also, at work we have been discussing patterns in terms of business process, software development, team dynamics, etc. These discussions have been quite interesting to me but I am not sure that I have seen the full benefit of what patterns can bring. My contention to patterns is there ineffectiveness for communicating a solution without a highly well defined context and problem to work against. How do you teach situations in the real world which will give an understanding of context and problem definition without understanding each viewer‘s background in the related area? There is a lot of room for misinterpretation and misapplication of the pattern without this understanding. On the other hand, design patterns continue to be popular and I assume this must be for good reasons.
This brings me to a decision on how do I define the factors in business technology success. Since I have a tendency to think of patterns only being useful once the context and problem synopsis are well defined I thought I would start there. Also, I am quite sure that it will be impossible for me to write an exhaustive list. Therefore, I will do my best to come up with a way to categorize the contexts and problem synopsis. The format that I have chosen for this list is:
- Context – describe the situation
- Problem – describe the issue or issues to be resolved
- Questions to answer – a list of questions which may be valuable in finding a solution to the problem
In order to find as many decision making contexts and problems for deciding on a business-driven technology solution, I will leave the solutions for later. In fact, I believe that the questions to answer will lead into multiple solutions and help better define the problem and context for their respective pattern definitions. I believe that the initial categories will be vertical market concerns, IT management, business agility, business value, and software development processes.
I look forward to hearing other‘s comments and suggestions on the format and categories described above. Formatted definitions of situations, issues, and questions to answer will follow in future posts.