Showing posts with label Technical Compliance. Show all posts
Showing posts with label Technical Compliance. Show all posts

August 21, 2009

Taking the Politics out of Enterprise Decision Making

Some people say power is primarily exerted through military might (“hard power”), others says it is through use of diplomacy—communications, economic assistance, and investing in the global good (“soft power”). Then, there is a new concept of employing the optimal mix of military might and diplomacy (“smart power”).

It’s interesting to me how the Department of Defense—military approach—and the Department of State—diplomatic approach—is as much alive and well in our enterprises as it is in the sphere of world politics to get what we want.

At work, for example, people vie—some more diplomatically and some more belligerently—for resources and influence to advance their agendas, programs, projects, and people. This is symptomatic of the organizational and functional silos that continue to predominate in our organizations. And as in the world of politics, there are often winners and losers, rather than winners and winners. Those who are the “experts” in the arts of diplomacy and war (i.e. in getting what they want) get the spoils, but often at the expense of what may be good for the organization as a whole.

Instead of power politics (hard, soft, or smart), organizations need to move to more deliberate, structured, and objective governance mechanisms. Good governance is defined more by quantifiable measures than by qualitative conjecture. Sound governance is driven by return on investment, risk mitigation, strategic business alignment, and technical compliance rather than I need, want, like, feel, and so forth. Facts need to rule over fiction. Governance should not be a game of power politics.

Henry Mintzberg, the well-known management scholar, identified three mechanisms for managers to exert influence in the organization (Wall Street Journal, 17 August 2009):

1. Managing action—“managers manage actions directly. They fight fires. They manage projects. They negotiate contracts.” They get things done.

2. Managing people—“managers deal with people who take the action, so thy motivate them and they build teams and they enhance the culture and train them and do things to get people to take more effective actions.”

3. Managing information—“managers manage information to drive people to tale action—through budgets and objectives and delegating tasks and designing organization structure.”

It is in the third item—managing information—that we have the choice of building sincere business cases and creating a genuine call to action or to devolve into power politics, exerting hard, soft, and smart influence to get what we want, when we want it, and how we want it.

When information is managed through the exertion of power, it can be skewed and distorted. Information can be manipulated, exaggerated, or even buried. Therefore, it is imperative to build governance mechanisms that set a level playing field for capturing, creating, calculating, and complying with a set of objective parameters that can be analyzed and evaluated in more absolute terms.

When we can develop decision support systems and governance mechanisms that take the gut, intuition, politics, and subjective management whim out of the process, we will make better and more productive decisions for the enterprise.


Share/Save/Bookmark

October 3, 2008

Enterprise Architecture Fit

Enterprise architecture helps organizations to ensure strategic business alignment and technical compliance of their systems.

Architecture and Governance Magazine, Volume 4, Issue 3, has an interesting article on “Business Fit vs. Technical Fit” by Larry DeBoever, in which he proposes a mapping of systems to demonstrate their EA fit.

Systems are mapped on a 2x2 grid that has business fit on the y axis and technology fit on the x axis.

The resulting quadrants provide a visualization of how systems map in terms of business alignment and technical compliance. Here is my view on these:

  • Lower left—low business and low technology fit. These are systems that are duds; theydo not meet business requirements or technology standards and should be sunset.
  • Upper left—high business and low technology fit. These are systems that are silos; they meet business needs, but don’t provide technical alignment in terms of interoperability, standardization, component reuse or alignment to the target architecture and transition plan. These systems need a technology waiver or should be retrofitted to comply with the enterprise architecture.
  • Lower right—low business and high technology fit. These are systems that are “toys”. They do not meet the requirements of the business, although they align nicely with the technology standards of the organization. Unless these systems can demonstrate business value, they should be decommissioned.
  • Upper right—high business and high technology fit. These are systems are optimal; they are in the EA sweet spot in that they meet business requirements and technology compliance parameters. These systems are sound IT investments for the organization.

This quadrant view of EA fit for systems is a wonderful tool for planning and also for conducting EA board reviews of proposed new systems or changes to existing systems.

For systems that do have business and/or technology alignment, Larry DeBoever calls for ongoing reviews and enhancements, due to “the problem of regression.” Since business needs and technology standards and plans are constantly evolving, our systems will be under constant pressure being forced to lower levels of business and technology alignment. Therefore, system development, enhancements and modernization is an imperative to remain competitive and on mission.


Share/Save/Bookmark

June 22, 2008

What Not to Tell Your Boss and Enterprise Architecture

ComputerWorld Magazine, 20 June 2008, tells us five things you don’t want to tell the CIO and which I believe tracks closely with the enterprise architecture function and goals, as follows:

  1. “All about the technology -- and nothing about the business”—just like enterprise architecture is about business driving technology, rather than doing technology for technology’s sake, so too the CIO is interested in aligning business and technology. So don’t just go to the CIO talking technology solutions unless you have a clear understanding and can articulate the business requirements.
  2. “There's only one solution”—in enterprise architecture and IT governance, we validate requirements against the architecture—the baseline, the target, and the transition plan. It is especially important to check if there are existing systems, products, and standard that can be used to meet user requirements, rather than building or acquiring something from scratch. There is rarely only a single technology solution for a business problem. Therefore, we need to evaluate the proposed new IT investment in terms of the return on investment, risk management, strategic business alignment, and technical compliance. Additionally, we need to review the analysis of alternatives to make sure we are effectively managing our scarce IT resources.
  3. “Bad opinions about your colleagues”—EA planning and governance makes information transparent and enables better decision making. With EA information, vetting of IT investment and collaborative decision making, there is no need to point fingers at each other over failed IT projects. Instead, through sharing information and bringing IT project stakeholders together, we all have input into the decision process and share the project risk.
  4. “There's no way”—With enterprise architecture, rather than say there’s no way to achieve enterprise goals or overcome technical challenges, we develop a target and plan for how we will do it. No, the goals are not achieved overnight, but rather by following a meticulous and vetted plan, usually over a period of three to five years, we can transform the enterprise.
  5. A surprise”—Bosses don’t like surprises. In a professional setting, we usually like rational thinking, process, structure, and planning, so that we can effectively deal with the chaotic world out there. EA planning and structured governance helps the organization stay on course and not get surprised or thrown. The planning process itself involves looking at our strengths, weaknesses, opportunities, and threats, and makes us more self-aware and proactive as an organization, so there are less surprises waiting to ambush us.

EA helps us to NOT have to tell our boss, the CIO, things he doesn’t want to hear, because we are proactive in our approach to planning and governance.


Share/Save/Bookmark

May 12, 2008

IT Portfolio Management and Enterprise Architecture

“IT portfolio management is the application of systematic management to large classes of items managed by enterprise information technology (IT) capabilities. Examples of IT portfolios would be planned initiatives, projects, and ongoing IT services (such as application support). The promise of IT portfolio management is the quantification of previously mysterious IT efforts, enabling measurement and objective evaluation of investment scenarios.” (Wikipedial)

IT portfolio management is a way of categorizing IT investments and analyzing them to ensure sound IT investment decisions. IT portfolios are frequently evaluated in terms of their return, risk, alignment to strategy, technical merit, and diversification.

Why do we need IT portfolio management—why not just assess each project/investment on its own merit?

The added value of developing and evaluating IT portfolios is that you can ensure the diversification of your investments across applications and infrastructure; new systems/major enhancement to existing systems and operations and maintenance; new R&D, proof of concepts, prototypes, and pilots; between strategic, tactical, and operational needs, and across business functions.

ComputerWorld Magazine, 7 April 2008, reports that Hess Corp., a leading global independent energy company, developed creative IT portfolios based on three types of initiatives:

  1. Bs—“business applications or business process improvement effort that’s aimed at increasing revenue or generating cost savings.”
  2. Es—“enablers” or projects to support business applications such as business intelligence, analytical systems, master data management, systems integration.
  3. Ps—“process improvement within the IT organization itself” such as standardizing the approach to applications development (systems development life cycle), project management, performance management, IT governance, and so on.

From an enterprise architecture perspective, we develop the target architecture and transition plan and assess IT investments against that. Again, rather than develop targets and plans and conduct assessments based solely on individual investment alone, EA should look at the aggregate investments by IT portfolios to ensure that the EA plan and subsequent investments are properly diversified. An EA plan that is overweighted or underweighted in particular IT investment categories can have a negative to disastrous effect on the organization.

IT investments represent significant expenditures to organizations and IT is a strategic enabler to mission, so messing up the IT plan with poor investment targets and decisions is costly to the enterprise.


Share/Save/Bookmark