I want to break out ideas I about building DSS the right way into three equally important categories. Typically, we look for three legs of a chair. Without one, the other two fall down. My three legs are Culture, Architecture, and Operations. I think Culture,Architecture,and Operations are the hardware that supports "the business model" - the content or the software. Software can change often but hardware changes less frequently. Typically, when you change hardware, it is quantum leaps better. Culture,Architecture,and Operations are harder to change than business models. Much care and consideration must be placed on them.

Culture is the accepted ways of living that all follow. Cutlure is the one thing that touches everyone in the organization and I personally think it is equally important to architecture and operations. In fact, my argument is that a broken culture can adversely affect architecture and operations. To support a business model such that it scale, it is inevitable that no one personal will ever know how the different functions of a business operate together to best serve the goal of the company to make money. A good culture makes finding out what you don't know easier.

Culture

=======

•  Break out problems so that people serving disparate roles in the organization can participate in culture, architecture, and operations in a quantifiable way that keeps technical debt to a minimum.
•  Open source your business model. The primary  business model could be explained through a wikpedia tool that all could access. It involves a conversation between all parts of the business on  how within the business model the company makes money. A merchandiser could say, these products are the most profitable. A business analyst with a data warehouse may see this statement and provide supporting evidence for or against this argument. A marketer might chime in and say yes these products are profitable but only when we run X Y or Z campaign or bundle them with A B or C products. Where the dust settles is a multidisciplinary view of the business. Look for conflicts use data to support the various claims. You will more quickly find the bottlenecks to the company's ability to make money.
• If possible without giving away the farm, open up your model to external freelancers who have a unique and unbiased opinion about what the bottlenecks of your business might be.
• The goal is to quantify technical debt and refactor culture/architecture/operations practices to reduce technical debt. An example is tieing up an engineer who could be solving more problems in operations or keep the lights on tasks. Another example of technical debt is tieing up engineers in projects that are poorly planned and don't make best use of the engineers time and talents.
• A good framework for such a culture if followed to the letter is Agile Development with SCRUM.
• Respect for others and their knowledge is very important in all of this. Credit should be given when conflicts and bottlenecks are corrected and the corporate engine runs smoother. It takes all types of personalities, knowledge, and problem solving skills to solve a complex problem.

Architecture

==========

Manual human to human conversation only goes so far. Things get lost in translation. We need tools that compensate for flaws in plain human collaboration.

• Wikis to define what works in the business model and let others make corrections.
• Data Visualization
• Star Schema Design and Best Practices
• Database specific optimization techniques
• Data extraction parallelization tools

Operations

=========

• Use the tools. Sure certain people have direct responsibility but operations should mean all members in the organization have tools to sample and alert on breaks in quality.
•  Automate what you can. Not everything can be automated. Certain mature processes that have been assessed as "not flawed" are good candidates. Automate when there is good organizational knowledge of what technical and business indicators point to a bad process run vs a good process run and good participation in early detection of issues. Operations folks can't catch everything but their role should be to field flags raised by others and eventually role the error conditions into the automation.

If I can consolidate all the ideas in this blog into their simple artifacts, I can build an army of freelancers that can build the hardware "Culture,Architecture,and Operations" tools and hand it off to the Corporations ("Those having a business model") and we can take their input and come up with the quantum leap upgrade.