Often times, Enterprise Architecture is very similar to the old story of the blind men and the elephant. The tale varies greatly in the telling, with the consistent part being that they all exam the elephant at the same time, yet each examines only part of the whole animal. When they discuss what they have examined, they all have completely different perspectives.
Even if only implied, all Enterprise Architecture (EA) frameworks include the notion of viewpoints. That is, we all agree that an Enterprise Architecture consists of things, and that those things can have different meanings, degrees of importance, immediacy of value, and even levels of aesthetic appeal to different people. Enter the Proof-of-Concept (PoC). The goal of a PoC is to serve as the remedy for the confusion in that old tale of the blind men and the elephant. Before the PoC, each stakeholder has a different view of the Enterprise Solution. A successful PoC does not need to change anyone’s point of view, it only needs to demonstrate to everyone’s satisfaction that it will fit the picture as they see it.
Why Do a Proof-of-Concept in Enterprise Architecture?
The value of a PoC is its ability to reduce risk. At the level of detail generally applicable to Enterprise Architecture, everything can work. It is easy to say that a portal will provide appropriately credentialed users with access to all internal applications, enforcing user permissions seamlessly through the use of an enterprise identity and access management package. It is almost as easy for the solution architects to take the logical architecture and create a physical architecture showing exactly how specific vendor packages and enterprise libraries will wire together to realize the vision of this enterprise portal.
However, the perception of enterprise architecture can be badly damaged when the actual implementation of this architecture fails to meet cost, time, or usability expectations. Building a small version of the planned solution before making a large resource commitment and business dependency on the outcome can demonstrate the value of Enterprise Architecture and greatly reduce the risk of wasted resources and lost opportunities.
Good Reasons to Do a PoC for EA
The portal scenario described previously was purposely both common and medium-complex. A PoC can be valuable for something very simple, such as testing vendors’ “ease of integration” claims that two products can work together — something that quite often is true only given a long list of limitations that are not always as easily discovered as the initial claim.
A proof-of-concept effort around a very complex solution is not only a good idea; some frameworks consider it mandatory. A popular notion in Enterprise Architecture discussions of late is that EA is about managing complexity. While EA is about much more than that, successful EA should result in managed complexity, whether or not it is a stated outcome. Conducting a PoC of complex systems is a good first step in managing complexity.
A good rule of thumb is, if you expect higher than trivial consequences when an architecture solution building block stops working, that solution deserves some level of PoC.
Bad Reasons to Do a PoC for EA
Just as a PoC to verify that two products work together as claimed is a good idea, testing whether two products from the same vendor using a standard interface will work together when you have a good support agreement in place is a waste of resources. Not because the vendor’s claims will always be 100% valid, but because the pieces are already in place to correct any issues. The project plan should simply include the normal amount of slack time to cover the inevitable unknowns that will occur during an implementation.
It is also a bad idea to conduct a PoC of something that has to be done. An example is an upgrade or migration dictated by compliance requirements. In this case, because the delivery team knows they are going to have to “do it for real” after a PoC they will generally use a throw-away approach, making the effort nothing but wasted overhead and delay.
The value of a Proof-of-Concept is the mitigation of risk (a core value of Enterprise Architecture according to many frameworks, and it’s just plain common sense). If the risk is minimal, the investment in mitigation should be proportional.
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.