First a governance must have a goal, we call it the VISION.
At the center of the governance, there are a set of RULES.The governance processes provide rules to the “governed processes”.
Once the GOVERNANCE is defined, one must think about :
- the COMMUNICATION of the governance
- the EXCEPTIONS and APPEALS that can apply to the governance
- the COMPLIANCE aspect : how to verify the governance rules are applied ?
- the VITALITY : when and how do we change the rules ?
Let’s think about a sample governance that we all know : the road code.
- The vision is that without a road code, the roads would become too dangerous.
- The road code is the governance, the set of rules, for driving a vehicle.
- The road code is communicated when you pass your driver license and via road signs.
- There are some exceptions to the road code, for example for the police and ambulances. You can appeal if you can prove that you were in an emergency case.
- Police controls are there to verify that you comply to the road code
- The road code should be revised from time to time. The vitality of the road code is ensured by the authorities.
This nice article on ROAM explains the acronym to be used to manage a risk:.
||The risk can be completely or partially avoided. If partial resolution, there is a residual risk
||The risk is not fully resolved/accepted/mitigated. Someone is assigned to work on it.
||We accept to take the (residual) risk.
||Mitigation is what we will do if the risk happens in order to reduce the impact
From January 1st 2017 until Sept 15th 2017, I worked as “IT Demand Excellence Manager” at PVGroup.
I managed a team of about 5 Enterprise IT architects and 5 Domain Experts (Non-Life, Life, Claims, Employee Benefits and Front).
This was a very good team to aim at the description of the complete Enterprise Architecture : from Business Processes to Technical Infrastructure.
Together we developed an interesting “Enterprise Architecture” process with several activities:
This was the ITDEME (IT Demand Excellence) process.
In addition we were busy with building some new digital foundations : ESB, ECM, IAM……
I just wanted to draw your attention to a SCRUM/KANBAN/XP acronym : INVEST.
INVEST represents the the characteristics of a good quality Product Backlog Item (PBI) :
See INVEST on Wikipedia
Sounds a bit like a SMART objective……
Here is an interesting thought of a colleague yesterday (Thomas Vermassen – Lead Architect ORES) on documenting IT systems:
You have basically two strategies for keeping your Enterprise Architecture knowledge under control.
The first one is to capitalize on people. If your organization is stable enough you can assign clear responsibilities and you should be able to find the right information by finding the right person.
The second one is to capitalize on documentation. Through deliverables you make sure everything is described as it should be. This is most suitable if you have a high collaborators turnover like when you work with a lot of sub-contractors.
The ideal world is probably to have both.
I’m a deliverable minded person and I so I tend to prefer the second one. I value information sharing as it often avoids job protection and silo thinking. The notion of deliverable is also linked to another value that I like : personal contribution.
Also when the architecture is complex I don’t see how you can just book a meeting with someone in oder for him to explain you the 100 business processes in scope. That must be why clever people write books……
How to prioritize tasks ?
- Lousy leaders
- Confusion regarding the strengths on the team
- Fear of failure
- Low expectations
- Lack of focus
- Insecure team members
Exceptional is the result of reaching beyon current performance.
“Scientists say that coffee and donuts release chemicals in the brain that creates the illusion that meetings are a productive way to get things done.”
1. Can you do the job?
2. Will you love the job?
3. Can we tolerate working with you?
Source : Forbes.com…