At this year’s Forrester IT Forum, time constraints and the sheer number of attendees’ questions for our keynote speakers resulted in many questions going unanswered. We’ve reached out to our analysts to answer some of these questions. Here they are:
Should architects be embedded in business, for IT projects? Why? And for what benefit? Where do you put project management in the business? For IT projects.
Answer from Jeff Scott, Senior Analyst:
There is no “should.” We will see architects located in IT and the business based on the organization’s goals and context. I see EA eventually breaking into three distinct groups over time. Infrastructure architects located in I&O who design the extended infrastructure, application architects located in IT who focus on delivery of business solutions, and business architects located in IT and the business who focus on business strategy. Business architects located in the business generally focus on business change and the benefit is providing a model of the business to executives that connects the disparate lines of business. I don’t see IT project managers moving to the business in any big way. Someone has to oversee all the technology-based issues in a project and usually that is the PM.
How can you build IT’s governance for standards, security, and laws?
Answer from Chris McClean, Analyst:
This is a very difficult process, especially as regulations, standards, and the technology landscape continue to change. Many companies have demonstrated success developing an IT control framework, which documents all of the proactive and reactive measures an organization takes to assure IT functions as desired. Control frameworks normally have several layers of detail, starting with high-level control objectives and getting to the low-level implementations of individual controls. The controls are mapped and applied to IT assets and assigned control owners. They are also mapped to specific regulatory requirements as well as IT risks that they help mitigate. For example, a single data security control might be applied across an entire set of databases, have a single control owner, meet requirements for four different regulations, and mitigate three different IT risks.
Establishing this level of control documentation helps build IT governance capabilities to set policy, monitor compliance, identify risk exposure, and make informed decisions for improvement. Instead of establishing completely new sets of policies and teams when laws change or when the technology department evolves, managers can map existing control types (with their detailed definitions, control test plans, etc.) as necessary. When business changes require a modification to the framework, it’s easier to do this centrally and then allow for any changes or exceptions required for various lines of business or geographies. Managers can also use the control framework to prepare for audits, track relevant metrics, and show improvement over time.
Instead of asking CIOs about perceived value do you ever ask CEOs, etc. about what measures they expect to see from IT?
Answer from Jeff Scott, Senior Analyst:
CIOs and CEOs should be talking regularly about how IT creates value. But CEOs don’t want a lot of detail. Fundamentally, they want to know four things regarding IT:
1. How is IT helping to reduce the overall operational cost of running the business?
2. How is IT helping to increase revenue or build new revenue opportunities?
3. Is IT itself being run efficiently?
4. Are technology risks being managed appropriately?
In responding to business requests, how do you centrally manage all the requirements for your projects?
Answer from Dave West, Senior Analyst:
I recommend splitting the requirements into backlogs around key business streams (in Lean, these are called Value Streams). You may align them around business service, business process, product or application (the last I would encourage you to avoid, but it might make sense in some organizations). The requirements can then be managed in terms of business priority and architecture risk, allowing teams to deliver them in the order that makes sense from both technical and business perspectives. These repositories of requirements enable us to start holding meta data with the requirements such as size, risk, value and as we deliver them other information associated with actual time taken and delivery velocity.
Some people do argue that ALL of organizations requirements should be held in the same place. While it is true that this approach does aid in reporting and automation a requirement really is without value, without context. Thus, by organizing them around context (process, service, and application) you provide some context. Also, requirements should linked to a systems specification, which should be organized around architectural principles.