What if your company built its factories and offices the way they build IT solutions?
Say that your company needs a new factory or office. It would form several subsidiary companies and a department to oversee them. One subsidiary would provide architectural services, one would serve as general contractor, and others would provide concrete, electrical, plumbing, and carpentry services. Still others would be formed to provide interior design services, and equip the offices and cubicles. Through these subsidiaries, your company would hire architects, managers, engineers, concrete workers, plumbers, electricians, carpenters, bricklayers, interior designers, and other laborers. None of these actually make the products or provide the services your company sells to its customers!
These subsidiaries would then create their respective processes and standards. These would differ from industry accepted processes and standards because ‘your company does things differently’. Finalizing the architecture and designs for the new factory or office would be a real challenge. The carpenters would have one set of requirements, while the managers would have another set; and so on across the subsidiaries. After reworking the requirements, the managers would solve the problem by creating a new role, the ‘Relationship Manager’. The Relationship Managers would be the points-of-contact for gathering the requirements from your business executives and managers. When a requirement appears too difficult, it is the Relationship Manager’s job to tell the business why the factory or office can’t have the required feature; such a double door or an escalator. Finally your company’s new factory or office would be delivered – late and over budget; assuming that the project did not fail – an all too frequent outcome!
When the factory or office was complete, your company would form another subsidiary company to run the facility. The workers in this ‘Operations’ subsidiary would spend most of their time compensating for and patching significant building defects just to keep the building running. Disasters would be common. After such disasters, the workers would restore the electricity following an ‘Uninterruptible Power Supply’ (UPS) failure, brace walls and floors when they ‘Went Down’, rebuild the elevator system following a ‘Crash’, or spray large quantities of toxic chemicals for ‘Bug’ infestations. Security breaches would be common as well. Intruders would enter the factory or building; some brought in as guests by careless employees. They would install viruses, worms, and Trojan horses to spy on your company, steal its secrets, and damage its ability to conduct business. Workers in both the ‘Security’ and ‘Operations’ subsidiaries would apply still more patches to prevent intrusion as well as detect and neutralize the viruses, worms, and Trojan horses. None of which actually make the products or provide the services your company sells to its customers!
Finally, your company would seek to make changes to the factory or office, or even build more factories and offices. This is necessary to keep the workers in the various subsidiaries busy. Remember, your company just made a large investment creating these subsidiaries!
So how do companies really get their factories and offices?
In the real world, there are two common approaches.
In the first case, your company would recognize the need for a new factory or office. It would engage an architectural firm specializing in the type of factory or office required. The architectural firm would present a few options that meet the business requirements. After some revisions, the selected option would be placed out to general contractors for bid. These general contactors likewise specialize in the type of factory or office required. The general contactor with the winning bid would then engage subcontractors for the concrete, plumbing, electrical, and so on. Your company would also engage a firm to design the interior, and layout the production lines, offices, cubicles, and other equipment. As planned, the new factory would be delivered ready for move-in. Your company would have contracts in place for janitorial services, and other routine maintenance. In this case, your company owns the facility but not the means to create it. In IT, this is referred to as ‘Out-Sourcing’.
In the second case, your company would lease the capability and capacity from a provider. If a factory is needed, a contract manufacturer is engaged. If an office is needed, a commercial space is leased. In this case, your company owns neither the facility nor the means to create it. In IT, this is referred to as the ‘Cloud’.
Does your company need its own IT Department?
Your company already trusts architects, contractors, and providers for the factories that produce millions, even billions, of dollars in products each year; or, for offices that safely support your workers and encourage their productivity. So why does your company insist on owning the computing as well as the means of creating it? Unless your company actually sells IT products and/or services, the IT is not a core business capability.
It’s time to bring in the professionals!
__Joseph Starwood (www.JosephStarwood.com)
Wednesday, July 14, 2010
Tuesday, July 13, 2010
Enterprise Architecture Roadmaps & Milestones
The Enterprise Architecture defines essential business and IT capabilities. The Enterprise Architecture Roadmap specifies the dependency-order among these capabilities. Realizing the Enterprise Architecture Roadmap requires that each milestone be implemented as changes to the IT Environment through IT Portfolio Projects and/or IT Asset Initiatives.
Whether separate or combined, most organizations perform IT Portfolio Planning and IT Asset Planning. This planning involves developing a business case and estimates to support prioritization and investment.
Enterprise Architecture provides the Technical Approach for each IT Portfolio Project and IT Asset Initiative. The Technical Approach, a directional document, identifies describes the Enterprise Architecture Roadmap milestone associated with the project or initiative. The description includes the general technical direction, risks, assumptions, dependencies, and benefits. The Technical Approach establishes a rational basis for prioritizing and estimating the project or initiative.
As each IT Portfolio Project or IT Asset Initiative begins, Enterprise Architecture provisions a Project Start Architecture [Cutter Consortium, 2010], also referred to as a Target Architecture [TOGAF Version 9, 2009]. The Project Start Architecture conforms to the established Technical Approach, and may add new Enterprise Architecture requirements or constraints defined since the planning stage. It presents the Conceptual Architecture for the intended IT solution, and may also include Logical and Physical Architecture aspects when providing specific direction to the project or initiative.
Architecture Governance is applied consistently. Milestone reviews (a.k.a.: Gate reviews) are conducted for the Technical Approach and the Project Start Architecture as well as the subsequent Software Architecture Document (SAD). When Architecture Issues arise, the Architecture Review Board (ARB) engages with the project or initiative to provide a resolution. In some cases, the ARB grants an Architecture Exception (Exemption) that may specify a future remedy.
__ Joseph Starwood (www.JosephStarwood.com)
Whether separate or combined, most organizations perform IT Portfolio Planning and IT Asset Planning. This planning involves developing a business case and estimates to support prioritization and investment.
Enterprise Architecture provides the Technical Approach for each IT Portfolio Project and IT Asset Initiative. The Technical Approach, a directional document, identifies describes the Enterprise Architecture Roadmap milestone associated with the project or initiative. The description includes the general technical direction, risks, assumptions, dependencies, and benefits. The Technical Approach establishes a rational basis for prioritizing and estimating the project or initiative.
As each IT Portfolio Project or IT Asset Initiative begins, Enterprise Architecture provisions a Project Start Architecture [Cutter Consortium, 2010], also referred to as a Target Architecture [TOGAF Version 9, 2009]. The Project Start Architecture conforms to the established Technical Approach, and may add new Enterprise Architecture requirements or constraints defined since the planning stage. It presents the Conceptual Architecture for the intended IT solution, and may also include Logical and Physical Architecture aspects when providing specific direction to the project or initiative.
Architecture Governance is applied consistently. Milestone reviews (a.k.a.: Gate reviews) are conducted for the Technical Approach and the Project Start Architecture as well as the subsequent Software Architecture Document (SAD). When Architecture Issues arise, the Architecture Review Board (ARB) engages with the project or initiative to provide a resolution. In some cases, the ARB grants an Architecture Exception (Exemption) that may specify a future remedy.
__ Joseph Starwood (www.JosephStarwood.com)
Organizational Change & Business-IT Alignment
Organizational change is never easy. It is also unavoidable. Organizations face an ever increasing rate of change. New business opportunities and threats emerge daily. Global competition impacts nearly every industry. Technology advances at a blistering pace. It even changes customer expectations about the products and services an organization provides and how it interacts with its customers.
Enterprise Architecture and Roadmaps can ease the pain of change. With these tools, an organization can navigate forward; avoiding pitfalls and delays. Even with these tools, people remain both the key resource for, as well as greatest challenge to, implementing organizational change.
Aligning groups and individuals throughout the organization builds synergy. This alignment must be architected ‘Top-Down’, and must address structure, roles, responsibilities, and objectives. The structure must reflect the scope of work to be preformed by a group as well as its interfaces with other groups. Roles and responsibilities must be defined so as to accomplish the scope of work and collaborate with other groups. The group and individual objectives must be aligned with the business and IT strategies and plans according to their function and level. This last item is perhaps the most overlooked aspect for many companies.
Aligning groups and individuals can be approached along three lines of reasoning: 1) Business-IT Alignment; 2) Financial-Execution Alignment; and, 3) Governance Alignment. Think of these as ‘Three Pillars’ extending from the Business through Enterprise Architecture to IT. When groups and individuals are aligned so as to support the Business-IT Alignment, changes to the vision become measurable results –IT solutions. IT investment becomes more focused as groups and individuals work within the Financial—Execution Alignment. Increasing synergy across the organization is apparent when groups and individuals engage in the Governance Alignment.
Metrics can be aligned using the ‘Three Pillars’ approach. Some organizations experience difficulty defining metrics that roll-up to meaningful business and IT KPIs. The ‘Three Pillars’ pose questions: 1) How well are business and IT aligned?; 2) How well are business and IT performing?; and, 3) Did we obtain the results we expected? The latter supports metrics that verify we conducted processes as we intended, and that validate what we intended is actually correct.
__ Joseph Starwood (www.JosephStarwood.com)
Enterprise Architecture and Roadmaps can ease the pain of change. With these tools, an organization can navigate forward; avoiding pitfalls and delays. Even with these tools, people remain both the key resource for, as well as greatest challenge to, implementing organizational change.
Aligning groups and individuals throughout the organization builds synergy. This alignment must be architected ‘Top-Down’, and must address structure, roles, responsibilities, and objectives. The structure must reflect the scope of work to be preformed by a group as well as its interfaces with other groups. Roles and responsibilities must be defined so as to accomplish the scope of work and collaborate with other groups. The group and individual objectives must be aligned with the business and IT strategies and plans according to their function and level. This last item is perhaps the most overlooked aspect for many companies.
Aligning groups and individuals can be approached along three lines of reasoning: 1) Business-IT Alignment; 2) Financial-Execution Alignment; and, 3) Governance Alignment. Think of these as ‘Three Pillars’ extending from the Business through Enterprise Architecture to IT. When groups and individuals are aligned so as to support the Business-IT Alignment, changes to the vision become measurable results –IT solutions. IT investment becomes more focused as groups and individuals work within the Financial—Execution Alignment. Increasing synergy across the organization is apparent when groups and individuals engage in the Governance Alignment.
Metrics can be aligned using the ‘Three Pillars’ approach. Some organizations experience difficulty defining metrics that roll-up to meaningful business and IT KPIs. The ‘Three Pillars’ pose questions: 1) How well are business and IT aligned?; 2) How well are business and IT performing?; and, 3) Did we obtain the results we expected? The latter supports metrics that verify we conducted processes as we intended, and that validate what we intended is actually correct.
__ Joseph Starwood (www.JosephStarwood.com)
Goverance and Enterprise Architecture Roadmaps
Many organizations struggle to establish and mature their Enterprise Architecture Roadmaps. The challenges they face are numerous: organizational change, cultural change, skills development, process change, technology adoption, etc. Enterprise Architecture Roadmaps improve alignment between business objectives and IT investment, and enhance communication between business and IT stakeholders.
Some organizations are finding support from the “10-Step Roadmapping Process” from the Enterprise Architecture Executive Council (EAEC; https://www.eaec.executiveboard.com/Public/Default.aspx). This process provides a customizable set of frameworks that embody the ‘Best Practices’ for building and maintaining sound roadmaps.
EAEC’s “10-Step Roadmapping Process” integrates Governance. Two aspects are emphasized: 1) Determine Ownership; and, 2) Establish Metrics.
Roles and responsibilities, especially around decision rights, are incorporated within the Determine Ownership aspect. To achieve Business-IT alignment the organizational structure and the group and individual performance objectives must also be considered and brought into alignment. The Determine Ownership aspect also sets the cadence for activities. This is critical to ensuring that progress meets key business deadlines while avoiding ‘quick shortcuts’ that jeopardize long-term business objectives.
Metrics are essential for establishing an objective and quantitative measure of success. EAEC’s “10-Step Roadmapping Process” emphasizes the success of Enterprise Architecture Roadmaps. However, metrics are also essential to measuring Business-IT Alignment, Financial-Execution Alignment, and Governance Alignment.
Just as Business-IT Alignment is architected ‘Top-Down’ from Business to IT, so to must Ownership and Metrics be architected ‘Top-Down’. This facilitates arriving at the minimum number of well-aligned roles and metrics necessary to achieve success.
__ Joseph Starwood (www.JosephStarwood.com)
Some organizations are finding support from the “10-Step Roadmapping Process” from the Enterprise Architecture Executive Council (EAEC; https://www.eaec.executiveboard.com/Public/Default.aspx). This process provides a customizable set of frameworks that embody the ‘Best Practices’ for building and maintaining sound roadmaps.
EAEC’s “10-Step Roadmapping Process” integrates Governance. Two aspects are emphasized: 1) Determine Ownership; and, 2) Establish Metrics.
Roles and responsibilities, especially around decision rights, are incorporated within the Determine Ownership aspect. To achieve Business-IT alignment the organizational structure and the group and individual performance objectives must also be considered and brought into alignment. The Determine Ownership aspect also sets the cadence for activities. This is critical to ensuring that progress meets key business deadlines while avoiding ‘quick shortcuts’ that jeopardize long-term business objectives.
Metrics are essential for establishing an objective and quantitative measure of success. EAEC’s “10-Step Roadmapping Process” emphasizes the success of Enterprise Architecture Roadmaps. However, metrics are also essential to measuring Business-IT Alignment, Financial-Execution Alignment, and Governance Alignment.
Just as Business-IT Alignment is architected ‘Top-Down’ from Business to IT, so to must Ownership and Metrics be architected ‘Top-Down’. This facilitates arriving at the minimum number of well-aligned roles and metrics necessary to achieve success.
__ Joseph Starwood (www.JosephStarwood.com)
An Approach to Business-IT Alignment
There are many methods and models for establishing and maturing Business-IT alignment as well as unifying IT disciplines – at least as many as consulting companies offering business and IT products and services!
Unfortunately, theses methods and models have limitations. Some are more applicable to one industry or another. Some are more applicable at the strategic level. Most emphasize the tactical level where IT products and services can be sold.
There is an opportunity to bridge the gaps between Business and IT, between strategy and tactics, and between development and operation of IT solutions. This opportunity and its challenges can be approached along three lines of reasoning: 1) Business-IT Alignment; 2) Financial-Execution Alignment; and, 3) Governance Alignment. Think of these as ‘Three Pillars’ extending from the Business through Enterprise Architecture to IT.
Enterprise Architecture bridges the Business Operating Model to the IT Operating Model. It establishes Business-IT alignment. IT Management and its many supporting IT disciplines bridge business objectives to IT automation and controls. These establish Financial-Execution alignment. Architecture Governance bridges Corporate Governance to IT Governance. It establishes Governance alignment. (Many organization place Enterprise Architecture team within the IT department. This may contribute to viewing Architecture Governance as a subset of IT Governance. However, Enterprise Architecture is primarily a strategic business discipline at the nexus of business and technology.)
There is good reason to utilize a ‘Three Pillar’ view. Some organizations are moving their Chief Architecture Officer (CAO) or Chief Enterprise Architect (CEA) under the COO in their executive structures. This is being done to ensure alignment between the Business Operating Model and the IT Operating Model. Some organizations are moving their CIO or CTO under the CFO in their executive structures. The CIO or CTO reports on matters of IT cost, risk, and performance. Recently, many organizations added a Chief Governance Officer (CGO) role to their executive structures in response to new regulatory requirements. The CGO reports to the CEO on matters of corporate governance and regulatory compliance.
__ Joseph Starwood (www.JosephStarwood.com)
Unfortunately, theses methods and models have limitations. Some are more applicable to one industry or another. Some are more applicable at the strategic level. Most emphasize the tactical level where IT products and services can be sold.
There is an opportunity to bridge the gaps between Business and IT, between strategy and tactics, and between development and operation of IT solutions. This opportunity and its challenges can be approached along three lines of reasoning: 1) Business-IT Alignment; 2) Financial-Execution Alignment; and, 3) Governance Alignment. Think of these as ‘Three Pillars’ extending from the Business through Enterprise Architecture to IT.
Enterprise Architecture bridges the Business Operating Model to the IT Operating Model. It establishes Business-IT alignment. IT Management and its many supporting IT disciplines bridge business objectives to IT automation and controls. These establish Financial-Execution alignment. Architecture Governance bridges Corporate Governance to IT Governance. It establishes Governance alignment. (Many organization place Enterprise Architecture team within the IT department. This may contribute to viewing Architecture Governance as a subset of IT Governance. However, Enterprise Architecture is primarily a strategic business discipline at the nexus of business and technology.)
There is good reason to utilize a ‘Three Pillar’ view. Some organizations are moving their Chief Architecture Officer (CAO) or Chief Enterprise Architect (CEA) under the COO in their executive structures. This is being done to ensure alignment between the Business Operating Model and the IT Operating Model. Some organizations are moving their CIO or CTO under the CFO in their executive structures. The CIO or CTO reports on matters of IT cost, risk, and performance. Recently, many organizations added a Chief Governance Officer (CGO) role to their executive structures in response to new regulatory requirements. The CGO reports to the CEO on matters of corporate governance and regulatory compliance.
__ Joseph Starwood (www.JosephStarwood.com)
Governance & Business-IT Alignment
Many organizations struggle to build synergy across their IT departments. They turn to consultants for expertise on unifying IT; obtaining assessments of their current IT alignment and maturity as well as recommendations for improvements. The organizations apply some of the recommendations, and adopt various methods and standards as a basis for aligning IT disciplines. Yet, in the end, they must ask themselves, “Did we get the results we expected?”
Governance is essential to establishing and maturing the interfaces between IT disciplines; thereby reducing and eliminating ‘IT Silos’. Governance verifies that we conduct each discipline and exchange information across each inter-discipline interface as we intended. It also validates that what we intended is actually correct. Governance provides management of IT disciplines during their normal operation. It also provides control for these disciplines when issues are encountered and exceptions (exemptions) are required.
Architecture Governance plays a key role in establishing IT alignment with the business. This is critical to validating that what IT intended is actually the correct thing to do for the business. It ensures that the Enterprise Architecture and Roadmaps conform to the business strategy and plans. The strategic alignment establishes a solid foundation for unifying IT.
Architecture Governance further contributes to IT unity through its integrations with other IT disciplines. It ensures that each Target Architecture, a milestone along the Enterprise Architecture Roadmap, furthers the strategic alignment while balancing short-term and long-term objectives. The resulting models and documents provide direction for the subsequent IT disciplines that develop and operate IT solutions.
Through Architecture Governance, professionals executing the IT disciplines are assured that their efforts are focused on doing the right things for the right reasons.
__ Joseph Starwood (www.JosephStarwood.com)
Governance is essential to establishing and maturing the interfaces between IT disciplines; thereby reducing and eliminating ‘IT Silos’. Governance verifies that we conduct each discipline and exchange information across each inter-discipline interface as we intended. It also validates that what we intended is actually correct. Governance provides management of IT disciplines during their normal operation. It also provides control for these disciplines when issues are encountered and exceptions (exemptions) are required.
Architecture Governance plays a key role in establishing IT alignment with the business. This is critical to validating that what IT intended is actually the correct thing to do for the business. It ensures that the Enterprise Architecture and Roadmaps conform to the business strategy and plans. The strategic alignment establishes a solid foundation for unifying IT.
Architecture Governance further contributes to IT unity through its integrations with other IT disciplines. It ensures that each Target Architecture, a milestone along the Enterprise Architecture Roadmap, furthers the strategic alignment while balancing short-term and long-term objectives. The resulting models and documents provide direction for the subsequent IT disciplines that develop and operate IT solutions.
Through Architecture Governance, professionals executing the IT disciplines are assured that their efforts are focused on doing the right things for the right reasons.
__ Joseph Starwood (www.JosephStarwood.com)
Subscribe to:
Posts (Atom)
