Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
MattHarding
Active Contributor
0 Kudos

Please Note

Within this blog, I’ll mainly use solution design and development as the main focus area, however with some tweaking of examples, this could apply to any part of supporting an SAP solution such as process design, functional configuration, basis, infrastructure, etc.

Is Solution Governance Important?

How many of you out there love to add comments and version history to all your code?

What about following a companies naming standards when you’ve been raised on a different standard?

Most of you will most likely want to do the right thing on all developments even if it is a little harder, but how many have been on a project under the pump (with unrealistic Project Managers) and you’ve made a decision to do a short cut temporarily and say - we’ll come back to that later - fully knowing that it is very unlikely you’ll be back (assuming your shortcut doesn’t introduce a problem later in production or during an upgrade).


Well this is just one point where solution governance, in my opinion, comes in.  It’s human nature to take short cuts, either out of necessity due to timelines, or otherwise.  But while it’s potentially acceptable given the circumstances; for any “temporary” shortcut, the solution will accumulate Technical Debt* that in some way or another, you will need to pay off one day.  Typically, the project (and it’s associated funding) walks away leaving the operational budget to pay it off and that is not likely to occur.


Just by having someone who “cares” enough to uphold strategies, principles, policies, guidelines, naming standards, ensure that peer reviews occur and are at a sufficient standard, etc; can make a huge impact to the ongoing quality of the solution.  So even if a short cut is required due to timelines; governance doesn’t have to change this short cut, but it can get the project (or business) to ensure it refactors the development before it drops into operations (or at least budgeted in a future project).

Of course there are many other good reasons for Governance, like providing a clear and consistent vision for all new solutions so that investment is made strategically, ensuring no compliance issues are raised, identifying the true position of a project (compared with the Project Status report), etc.

* Thanks to Al Templeton for introducing me to this term. Love this analogy.

Is Speed or Agility important?

With governance now in place, you now have to deal with the perception that all projects appear to cost more due to the extra effort of governance that projects need to commit to. In addition, the business may get frustrated as governance can bottleneck your projects if processes are not efficient or projects are not engaging correctly (either accidentally, or deliberately but that’s a whole new blog to cover that issue off).  Then there's times where the business is not exactly sure what will work, hence the requirements need more agility than you can typically govern.

You can sell governance easily when you save the day or avert a disaster, but when things go smoothly; it’s almost impossible to measure the investment of paying the Technical Debt up front against the accumulating cost of the Technical Debt plus interest that is not paid off (as I said - I love this analogy).

This is probably not a problem for your big projects - everyone knows that these are important to govern well, but smaller projects typically want to be agile, or deliver quickly at lower cost. In these scenarios, full strength Governance introduces a delay and comes at a cost which may be a delay or cost that is too high for your business (and I’m sure many knows what typically happens next).

Is innovation important?

Fo some industries this may not be an issue (questionable though).  At least in the mining, utilities and retail industries I believe innovation can make a huge impact.  Maybe from process efficiencies through an offline mobility solution, or through better engagement with customers with customer analytics (check out Smart Meter Analytics on HANA as a very cool piece of tech).  While innovation can be a big project, I typically think introduction of innovation best starts on a small scale.  This avoids too much bleeding of your bleeding edge solution and the ability to remain agile (even stopping the project early if necessary as an example).

The great thing about innovation within a business, is the business typically loves this stuff almost as much as the lucky developers involved.

Capital Expenditure or Operating Expenditure?

This is another blog waiting to be written as it’s a constant battle to get the right amount of operational budget to support governance, and then there’s the battle around architectural deliverables being treated as a capital and not an operational expense.  i.e. The CFO wants to lower operating expenditure but governance teams don’t want to be treated like a tax on projects but a “free” service including in the operating budget.  So the trick is how to get sufficient budget to support good comprehensive governance (eg. It’s not one FTE we’re talking about here).

What’s the idea?

Let’s look at just a selection of the mandatory experience or skills for each area (generically thinking around SAP Solution Design):

Solution Governance:

  • Good knowledge of the SAP solution and roadmap in order to review SAP Solutions for company XYZ
  • Good knowledge of the company XYZ’s vision, strategies, processes, etcUnderstands best practices in SAP
  • Ability to quickly review solutions to ensure compliance with all company principles, policies, strategies, compliance, etc
  • Owner of naming and design guidelines for SAP Solutions

Speed/Agility:

  • Ability to quickly take business requirements to identify the candidate SAP solution, proposing new SAP solutions as required
  • Good knowledge of the company XYZ’s vision, strategies, processes, etc
  • Ability to develop solutions that comply with all company principles, policies, strategies, compliance, etc

Innovation:

  • Understanding and positioning of SAP’s roadmaps in order to identify where innovative solutions may address business requirements
  • Ability to develop solutions that comply with all company principles, policies, strategies, compliance, etc
  • Define naming and design guidelines for new SAP Solutions

I could think this out further (considering transition to support activities as an example), but in short, there’s a lot of cross-over of these roles, and if you look at this in a cycle; being able to Govern the solution, means you can provide, when required, speedy strategically aligned solutions and if required, innovative solutions, which if new technologies are involved, need to be governed.  It’s a bit of a stretch, but this then allows me to throw an obligatory diagram into this blog showing this cycle (with Innovation where required).

Figure 1 - Obligatory picture or model in blog - Describing the SIG model

So in short, the idea is to build a governance team which also has the ability to release individuals or groups of individuals for an annual average of 50% of their time to take control of any urgent or innovative projects and develop them in an appropriate way and an expedited manner while still being governed but also establishing any principles, strategies, etc; for new technologies/approaches as required.

Further to this, we’re now talking about a solution governance team which does a good percentage of capital work; hence win-win for both the Architecture Governance Manager in terms of head count and capabilities, and the CFO in terms of lower operating cost (not to mention lower Capital expenditure)!

An Added Bonus

I’ve been a governance architect myself, and the one thing that worries you most is the fact you can start to lose your edge if you don’t actually develop a production solution for yourself occasionally, especially on new solutions.  And when you’ve done this, apart from being a perk just to take part in innovative solutions, it also adds credibility to project teams when you do actually know what you are talking about.

Also, when so often you are tasked to correct the direction of projects, it's great to be enabling the business directly which I believe is also a good way to retain these people, not to mention investing in your own people and not contractors.

The Catches

Solution governance is providing an independent review or at least transparency around a solution, hence throwing an entire team into doing a project means you no longer have anyone who can govern the project.  By keeping all the Governing team at least 20% operating expenditure during assignments this should not be a problem.  Heck, why not throw in a Friday Innovation afternoon while you're at it like SAP does!

Lastly, urgent and innovative projects should not be super frequent events.  This is not a “bypass all planning and release management” approach to SAP Solution Governance.