A common problem facing business analysts and IT leaders is the question of ownership when trying to implement governance models in organizations. Governance assumes ownership and accountability to ensure results are delivered with consistency. Often times, IT leaders attempt to assign ownership of assets like Data or Processes to business folks. This is a slippery slope and can often lead to heated battle fronts and/or stall out projects and efforts for implementing governance.
Discrete problems work well with component architecture, which fits nicely into technology paradigms for design. However, fluid problems (like processes) cross over multiple business areas and the same happens when you bring services up to higher levels of granularity (through bundling of primitives into composites). There may not be any single owner for these (nor would this make sense). The question is "Do we need an owner for technical / business artifacts ?" or does the business architect and/or business analyst simply need to ensure that the artifact addresses the business needs appropriately ?
Perhaps a bigger question is "Why would business folks care about owning Data or Processes ? " They are hired to execute and deliver operational services and/or facilitate change (via a project). Processes are corporate assets as are business rules and software and hardware. These should be defined, built, and implemented by process / software / hardware experts. These experts should govern these artifacts using appropriate change management procedures. The business folks are consumers of the services provided by these artifacts and their only responsibility should be to define their desired outcomes w/r/t the jobs they are trying to get done.
Ownership belongs with the service providers not the consumers. Once IT folks reorient themselves as service providers, these questions of governance become straight forward and the exchange between IT & Business folks falls into place like any other customer-provider relationship.
Comments