Expanding on my previous post on accountability, fostering alignment across the enterprise is really driven from multiple angles: market opportunity, technology opportunity, capability and business operations--all which create a business strategy. In that are 5 main tenets: effectiveness, competitiveness, agility, accountability, and efficiency.
One of the key objectives of Visual Studio Team Foundation server is to create an environment where teams can collaborate and leverage past experience; this is where I think the real value of IT lies. A key item I have begun to include in my documents is that we should have multiple value propositions for each objective--a value proposition from the business and one from IT. VSTF allows us to foster collaboration and create value, but we still have to measure the effectiveness in translating business vision and strategy. Enter Balanced Score Cards.
BSCs are about clarity and turning vision and strategy into action and providing feedback on those actions. Most importantly, BSCs are more than just about profit and cost reduction, which is great, but only a segment of issues. BSCs allow for balance:
"The balanced scorecard retains traditional financial measures. But financial measures tell the story of past events, an adequate story for industrial age companies for which investments in long-term capabilities and customer relationships were not critical for success. These financial measures are inadequate, however, for guiding and evaluating the journey that information age companies must make to create future value through investment in customers, suppliers, employees, processes, technology, and innovation."
Every project has basic elements that can be used by BSCs: customers, budget, learning opportunities and growth, customer satisfaction, etc. and as such, architecture should be mapped to those elements. Visual Studio Team System Architect and Team Suite SKUs include some great visualization tools to provide a visual element to our complex systems, such as a datacenter view and code entity relationships.
In order for projects and feature teams to collaborate effectively, first they must identify which goals are shared. Those goals must then be mapped back to business strategy in a way that provides clarity. Since most human beings are visually oriented, the addition of visual views of our systems allow us to quickly and succulently (a picture is worth a thousand words) describe and recognize reusable technical areas. However, in order to successfully provide shared systems or components, one must leverage standards that exist (global, industry, team, project, etc.), focus on key integration requirements, as well as use extensibility models and OOP techniques to handle special cases. This ensures that components are developed against a clear set of goals that is transparent to everyone. Other projects then can use these views, which can be exported as images, to identify if and where the components or services provide value to their objectives during their envisioning and planning phases.
As we shift into this kind of thinking we are placing more and more emphasis on process, that is, creating deliverables consistently and reliably whether it's a process to support the application, a business-oriented process (such as a human to human workflow), or strategic planning. There are several key areas we can focus on to improve process efficiency such as having a managed workflow, minimal variation in our processes, or stakeholder/participant insight.
One key item to realize when thinking about how this architecture decision could be useful in the future is to be aware that future changes should not hurt. This can be done through encapsulation which then allow improvements to be implemented with little overall pain to the service or component itself and to other applications that are dependent on it. It is through encapsulation that you can standardize how instances of your process, component, system, service, etc. are created or invoked, and automatically test normalized user scenarios to provide quality and consistency. With these scenarios you can derive values for various metrics, such as performance, which are reflected in the BSC.
You analyze a high priority user scenario and see that in the workflow there are a number of calls to your web service that reduce the responsiveness of the calling application due to the overhead of running the HTTP request and parsing the response. You then optimize this scenario by reducing the amount of fine grained calls to your service by providing a coarse grained interface to be used by calling applications.
As teams adopt these practices the organization drives toward excellence by implementing consistent best practices, optimizing return on investments (ROI), and increasing communication by collaborating, which is eased by a consistent context for exchange of information. The dependency of another application to your own forces quality up and dissolves team indifference.
Shared components and services significantly improve communication and alignment with business objectives
- In order to drive the need for dependency on a component, it must clearly communicate its value propositions and be integral to the value chain of another project
- To maintain order, policies must be enforced
- Each component or service has value and associated cost which can be measured using a Balanced Score Card
- Each component or service can be in-sourced, outsourced, and multi-sourced
- The encapsulation of business capabilities promotes
- continuous improvement
- flexible souring choices
- teaches an organization about itself
- continuous improvement