In an EA PoC, Aim First, Fire After
So, if a PoC should be conducted to mitigate risk, there needs to be a clear understanding of the following:
- The risk that needs to be mitigated
- The consequences of failing to mitigate it
- What defines a successful mitigation of the risk
If any of those three are unknown, do not start work on the PoC until you understand the proof, the concept, and the reasons for both.
When attempting to complete the PoC quickly, buy as much time as possible to prove the concept thoroughly. Many "PoCs" are in production today, and the reason why maintenance costs keep going up despite improved processes is that while the processes are followed to the letter, the spirit of the underlying concept(s) are completely forgotten (or unknown).
Continuous Involvement, Consistent Messaging
So, how do you make a PoC as thorough as possible when there is inevitably pressure to succeed (though one important reason to do a PoC is to discover if it can fail)? And when any level of success can be misconstrued to be total success? First, show progress early. To business stakeholders, a PoC is doing something that is not making or saving money, it is only spending money. These stakeholders want, need, and deserve to know that their IT investment is being managed wisely. The difference between a successful and celebrated EA group and a struggling and mistrusted one is how stakeholders perceive their value. Structure the PoC effort to create demonstrable progress as early as possible.
For example, making progress early in a portal PoC would mean having the basic UI elements in place as quickly as possible, even if there is no real data behind them. For an infrastructure PoC, have cells marked "complete" in a project plan. No matter what the evidence is, make sure that it is easily recognizable to key stakeholders as early as possible.
The danger of showing progress early, however, is that the degree of progress can easily be misinterpreted by those who aren't technically deep (i.e., those who are paying for the PoC). As some frameworks do, this is an important point in the process to mitigate the risk of presenting a premature PoC proof without a validated concept. Always follow the validation of progress with an immediate reminder of the goal that is being pursued and time/effort/dollar allotment that was agreed upon to reach that goal.
It also helps increase buy-in when presenting such reminders if you can claim that you haven't used all committed resources to reaching the goal. Try to get there early, under budget, or both when possible. Just don't do it too often or it may damage your credibility.
The tale of the blind men and the elephant has many different endings. In some they never come to consensus; in others they discover the elephant by combining their understandings. In Enterprise Architecture, the happy ending is when, after having concluded that all of their inputs fit together no matter how different, the blind men all climb on top of the elephant and ride comfortably in the same direction.
The thing about Enterprise Architecture is that it is based on common sense. Although Voltaire is credited with saying that it isn't so common, those who possess common sense often seem to get the most from being reminded of things that are.
Finally, for a view from the negative side of this concept, there is an interesting article at stevenimmons.org.