Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

The Value of the PoC in Enterprise Architecture

With appropriate planning, management, and presentation a Proof-of-Concept can become a key part of a successful Enterprise Architecture


advertisement

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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap