Disciplined Agile

We have recently updated our book, Choose Your WoW!, which overviews the Disciplined Agile (DA) tool kit and provides a detailed description of the Disciplined Agile Delivery (DAD) portion of it. Our primary goal was to bring the book into PMI publications so that we could offer it on PMI marketplace.  We also wanted to share with you the changes that we're making to the rest of the DA tool kit.  

In this blog I will focus on the changes that we've made to the DA Overview diagram.  Figure 1 shows the previous version of the diagram and Figure 2 our updated version.  When PMI purchased Disciplined Agile in August 2019 we had several streams of evolution underway at the time, all of which are reflected in Figure 2.  PMI also purchased Net Objectives so that we could merge their FLEX framework into DA, forming what has now become the Value Streams layer of DA.  Al Shalloway and I will go into more detail on this in future blog postings.

Figure 1. The previous Disciplined Agile overview diagram.

Figure 2. The new Disciplined Agile (DA) overview diagram.

In addition to modernizing the look of the diagram, you'll notice several important changes:

1. We simplified the diagram.  We simplified the Disciplined Agile Delivery (DAD) layer into a single process blade.  Figure 1 shows the six lifecycles supported by DAD, but we've consistently heard that this overcomplicates the overview diagram.  The lifecycles still exist but we're not showing them at this level any more.
2. We've reworked the layers. The original layers (DAD, Disciplined DevOps, Disciplined Agile IT, and Disciplined Agile Enterprise) reflected the order in which the DA toolkit evolved.  The new layers are:

• The Foundation layer is where fundamental agile and lean concepts; our evolved approach to the DA mindset that is based on principles, promises, and guidelines; roles; and team structures are captured.  This layer encompasses concepts and strategies applicable across your organization.
• The Disciplined DevOps layer has pretty much remained the same, with the exception of the visual refactoring of the DAD layer into an explicit process blade.
• The Value Streams layer is where we have merged FLEX into DA.  Very exciting things are happening here that we'll cover in future postings.
• The Disciplined Agile Enterprise (DAE) layer encompasses the activities that support the value streams that your organization offers to customers.

3. We've evolved some process blades.  Several process blades of Figure 1 have evolved:

• Reuse Engineering has become Asset Management to better reflect common enterprise practice.  
• Procurement has evolved into Vendor Management to reflect the full lifecycle of VM, not just the procurement portion of it.  
• Program Management has been refactored, with a Program lifecycle being explicitly called out within DAD and Program Management itself elevated out of the software development space to address all aspects of Program Management (as per PMI's existing standard).  
• DAIT, formerly a layer, has become the Information Technology (IT) process blade which focuses on the coordination of IT efforts across value streams.    
• DAD is now a process blade rather than a full-fledged layer.  
• Control was renamed back to Governance.  We had a lot of feedback that Control didn't reflect DA's lean governance philosophy.

4. We've added some process blades. As you can see in Figure 2, we have introduced 3 new blades:

• Research and Development, a critical aspect of an organization's capacity to innovate.
• Strategy, to guide an organization over the long term.  We're adopting many great ideas from PMI Brightline.
• Transformation, to guide you in organizational change.  We've combined great strategies from our own transformation practices (pre PMI) at Disciplined Agile Inc., those of Net Objectives, and the PMI Brightline transformation strategy.

 As you can see, there is a long list of potential blog topics to describe how DA has evolved, and continues to evolve.  Next up will be an overview of our updated approach to describing the DA mindset. Please stay tuned!

Free Downloads

We have made several Disciplined Agile (DA) posters available to you for free download, including a Disciplined Agile Overview poster.

Photo credit: Umanix

----

Disciplined Agile (DA) has always recognized that some teams work remotely and now, given the need to respond to the challenges presented by COVID-19, we are applying our own advice with our DA training offerings.  

Starting in early March we reworked our instructor-led training (ILT) offerings so that they can be delivered remotely by qualified instructors. In the picture above we see two Certified Disciplined Agile Instructors (CDAIs) from Umanix delivering the a Disciplined Agile workshop virtually.  As you might expect, the instructors are using video conferencing software to work through the courseware with the students, but there's much more to it.

The DA workshops have many hands-on exercises, both games and case study work, in which students collaborate to learn critical concepts and techniques.  In the bottom left-hand corner you see an exercise in which a group of students are in a breakout room and are working together.  In the face-to-face (F2F) version of this exercise students move cards around on a table and discuss their decisions as they go.  In the virtual version they move images around on the screen.  In both cases the instructor is observing and helping the students where necessary.  Once the group work is over the students then do a "wall walk" by going into each of the breakout rooms to see and discuss how other groups approached the problem.

We've been very lucky in that one of our DA Training Partners has been delivering DA training to globally dispersed teams for years.  They agreed to take the lead and share their experiences and techniques with our other training partners so that we can successfully bring DA training to you remotely.  In short, we've been in a position to apply proven remote training strategies so that your learning experience is the best that it can be.

Don't worry, DA Training Partners will still be offering face-to-face training once it becomes safe to do so again.  And we'll also continue with virtual workshops as well, because my gut tells me that we're going to have a lot more distributed Disciplined Agile teams in the future.

-----

Please visit Disciplined Agile Training to discover our current workshop offerings.

While face-to-face (F2F) collaborative work is often preferred, many of us now find ourselves in a situation where that may not be an option for the foreseeable future.  Recently many organizations have asked their staff to work from home whenever possible.  For those of us who have been working remotely for years this is business as usual, but for many of our colleagues this is a new situation.  We all need to get better at working remotely, and an important aspect of that is making teleconferencing calls effective.  So I thought I would share some tips that I've found to work well.

I've organized these tips into four sections:

1. Joining a call
2. During a call
3. Organizing your environment
4. Planning and facilitating a call

Joining A Call

The best calls are the ones that start well, and an important aspect of this is people joining the call well.  Here's what you can do:

1. Join on time. When you are late for a call either making everyone else on that call wait for you or you interrupt the conversation when you do join.     
2. Announce yourself to a small group. When your call is with a handful of people, and when you're on time to the call, then it's polite to join with a simple "Hi, Scott's here" or something similar. 
3. Don't announce yourself to a large group. If the number of people on a call is large, and the limit for "large" in this case is likely 7 or 8 people, then announcing yourself as you join becomes an annoyance.
4. Join on mute. We all hate it when someone is on a call and their background noise drowns out the conversation.  An important aspect of avoiding this is to join a call on mute so that you don't disrupt what is currently in progress. Once you're on the call, verify that you're muted. We've all seen people mistakenly think they're muted when they're not, so let's learn from that and start building habits to avoid these embarrassments.  
5. Join with video turned on. We'd really like to see you!  A lot of information during a conversation is communicated visually, so bandwidth permitting it's preferable to have everyone turn their video on. You'll find that doing so will make your calls more interesting and valuable.

During a Call

It's the responsibility of everyone on a call, not just the person facilitating, to ensure that the call runs smoothly. Here are a few ways you can do that:

1. Remain in the moment. I know it's hard, particularly if you spend a lot of time on calls, to remain focused on the current conversation.  We're all tempted to check email or multi-task in some other way to alleviate the boredom.  Then suddenly we realize we missed something important and either need to let it go or ask to have the information repeated to us.  
2. Remain muted if you're not speaking. Sound quality is a critical success factor for calls.  Although it takes a bit of effort to turn the microphone on and off it can make a huge difference for the overall sound quality.  A nice side effect of this habit is that it helps all of us to remain in the moment.
3. Dress like you're at work, because you are. We dress differently at home than we do when we go into the office. Although we're working from home and want to dress down we need to remember we're still working so should dress accordingly.  Yes, it's ok to loosen up a bit on your personal dress code when doing so, but recognize that there are limits.  My advice is to dress as if it's a "casual clothes" day at your office.  
4. Go on mute.  I really can't say this enough.
5. Introduce yourself when you talk. When you're on a call with people whom you infrequently work it can be useful to start with "It's Scott, I was thinking..." so that people can learn who you are.  Although most video conference software will indicate who's talking at any given moment you may have some people on the call who don't have a video feed, perhaps because they dialled in with a phone.
6. Look into the camera when you speak. If this was a face-to-face (F2F) conversation you would very likely look people in the eyes when you're speaking.  The teleconferencing equivalent of this is to look into the camera.  This is harder than it sounds because it can be very tempting to look at yourself in the window showing your camera feed.
7. Speak up.  We would really like to hear you.  An interesting side effect of looking into the camera when you're speaking is that you're very likely aligned so that your microphone can pick up what you're saying.
8. Speak slowly.  We often find ourselves on calls with people who have different accents and who may not be fully proficient with English yet.  If you find yourself in this situation people will appreciate you making the effort to be understood by them.
9. Did you remember to go on mute after speaking?  I keep repeating this point because it's an important habit to adopt.  
10. Remember that others want to collaborate too. We want everyone on the call to participate where they can, which means we all need to recognize that we need to share the air time with others. 
11. Be flexible. Many of us have kids, pets, and other family members who may choose to barge in during the middle of a call. It happens, and frankly can lighten up the mood in many cases. On that same note, none of us are perfect.  Sometimes we're late, sometimes we forget to go on mute (have I mentioned how important sound quality is?), sometimes we may not be perfectly groomed, and so on.

Organizing Your Environment

Think about the last time you were on a call, and you were looking at other people over the video feed.  You were probably assessing how they were groomed, how they were dressed, and what the state was of their work area is.

1. Be aware of what's in the background. This can be hard to control, but do your best to tidy things up. 
2. Point your camera directly towards you. This will make it easy for you to look directly into the camera when you're speaking and very likely present you in the most flattering light possible.
3. Consider getting a headset. Although they can be uncomfortable at first, headsets can both improve the quality of the sound that you transmit and if you have noise-cancelling headphones easier for you to hear.  
4. Be in a well-lit space. We've all seen people who look like they're working in a dungeon and that's mostly because of poor lighting.   Natural lighting is best if you can do it, and the easiest way to achieve that is to set up either near or better yet facing a window.  Otherwise you may need to arrange light sources so that they project towards you. 
5. Test your equipment before the call. If you're new to teleconferencing, or you've changed your setup, you might want to consider doing a quick one-on-one call with someone to test if everything is configured correctly.  We don't want to force people to wait while we adjust our setup to get it working.  
6. Familiarize yourself with the software. There are many teleconferencing packages available to us and they all work differently.  If the software is new to you, or if you haven't used it lately, watching a quick training video is likely a good idea.
7. Be aware of the ambient noise. We've all been on calls where someone is dialing in from their car, from the airport, or from their local coffee shop.  The ambient noise is often worse than they think and it can be very distracting.  So you if you can't avoid calling in from a noisy environment then, you guessed it, go on mute as often as you can.  

Planning and Facilitating a Call

Nobody likes wasting their time on a call where nothing is accomplished.  Effective planning and good facilitation can go a long way to making a videoconferencing call successful.  

1. Have an agenda.  People need to know why you are having the call so that they know what is expected of them.  Perhaps more importantly, they also want to determine whether they need to be on the call at all.
2. Keep the attendee list short. Although this can be hard, I always try to identify who is required to attend, likely because they are actively involved in the topic of the call, and who is optional because they may need to listen in to be aware of what we're doing. 
3. Prompt people to participate.  Some people are shy, particularly when they are new to videoconferencing.  So keep an eye out for this and occasionally ask someone who hasn't spoken lately if they have anything to add.
4. Schedule time between calls. A courteous practice is to have a 5 minute "bio break" between calls.  The easiest way to do that is to adopt the practice of ending calls at :25 or :55 rather than at the bottom or top of the hour respectively.  
5. Start on time. When I'm hosting a call I will typically start the software a couple of minutes before the call is scheduled to begin so that we can start immediately on time.  
6. End on time. Many of the people on the current call may have something else scheduled, perhaps another call, immediately after this one.

One last bonus tip: You are welcome to copy the image at the top of this article and use it as a quick reminder list of the key tips in this article.  Print it and tape it to the side of your monitor if you like!

Please feel free to share this article with others or print it out so that you can keep it handy.  We’ve also put together a short tip sheet that you can tape to your monitor.

I would love to hear about any other tips you would have so that I can update this blog and share them with others.  Thanks in advance!

Since Disciplined Agile (DA) joined the PMI family in August 2019 we've gotten a collection of questions from people along the lines of "Why is there a difference between the advice in DA and PMI's advice?"  So I thought I would write a few blogs examining why that is.  This is the first.

There are several reasons why there are differences between existing DA and existing (non-DA) PMI materials:

1. They were created by different groups of people.  It's natural to get different takes on a topic from different groups of people.   
2. DA took on a broader scope than PMI traditionally has (until now). PMI has focused on project management and critical topics surrounding it such as program management, portfolio management, and governance (amongst others).  That is the scope that PMI chose to focus on and has frankly done a very good job at doing so.  The scope of DA, on the other hand, has been to address how to take an agile/lean approach to all aspects of an organization, including but not limited to management.  This is a much broader scope than what PMI has taken on, until now. As a result DA addresses marketing, finance, enterprise architecture, operations, governance, software development, and many other process areas that are important to modern organizations.  Why is this broader scope important to PMI?  Because all of these areas need to be managed/led and governed.  I believe there's an interesting implication there. ;-)
3. PMI has traditionally gone very deep into management and the governance of management activities.  I'll let the great material in our standards and practice guides speak for itself. As Stan Lee was prone to say, 'Nuff said.
4. DA has traditionally taken a more holistic view.  DA includes both what is being managed as well as the management/leadership of it.  For example, consider The Standard for Program Management Fourth Edition.  Where the existing PMI standard does a fantastic job of addressing the management aspects of a traditional program it doesn't go into critical "doing aspects" of programs such as how to address architecture, requirements, and quality activities (it does address planning and management though) for example.  This isn't meant to be a criticism of the standard but merely an observation - When we (PMI) developed the standard our focus, and once again rightfully so, was on management and governance.  It was not on the overall, holistic view of what occurs with a program.  With DA we choose to take a more holistic view, as do agile frameworks such as SAFe^R and LeSS amongst others, and go beyond management and governance.  

My point is that there are very good reasons for the differences between what is in DA and what PMI has traditionally focused on.  These differences are an important aspect of the value proposition of DA for PMI, and more importantly for our membership, because we can learn from these differences and then improve and grow based on those learnings.  We're currently evolving DA based on the great material encompassed by the existing PMI standards and practice guides and our hope is that the existing PMI offerings will evolve to reflect Disciplined Agile ways of working (WoW) too.  

In the next blog in this series I will do a deep dive into the differences between DA's take on Program Management and the PMI Program Management Standard.  I suspect this will help to make some of the ideas in this blog more concrete and it will certainly make the opportunity before us a bit more explicit.

By Jeev Chugh, CDAP | CDAI and Joshua Barnes CDAC | CDAI

Enterprise agile transformation roadmaps using Lean Change are often fueled by the desire to deliver value faster with increased flexibility.  They start with replacing traditional (waterfall) delivery methods with an Agile way of working, using pilot teams to validate early decisions on how to experiment with aspects such as team formation, lifecycle (agile, lean, continuous delivery, etc.) practices and techniques, and so on.  What team members and business and technology leaders alike quickly glean is that the mind shift to collective ownership of the work, decentralized decision making, and all the energy to shift to self-organizing teams is just the first step.  A big step, but one in a long journey.

To truly achieve the sizable outcomes from these enterprise transformations, many aspects beyond that of individual agile teams achieving a good level of maturity in “their” agile ways of working are needed.  One of the shifts that enables such outcomes is adopting a Product Portfolio operating model.  In this model, we transition from assembling a team to deliver a fixed scope via a project and then disband as the project ends to a long-lasting stable team delivering business outcomes via continual improvement of a product.

Along with this change comes the realization that traditional waterfall methods of budgeting and project cost accounting that requires upfront plans and budgets, is in inherent conflict with Agile ways of working; especially so when the agile approach uses a Lean Kanban-based lifecycle (very small batches) or Lean Continuous Delivery (no batches) lifecycle. Thus, to successfully scale Agile, enterprises must work with business and Finance partners to move beyond traditional project-centric funding models and adopt a product-centric funding model that enables rolling-wave planning, dynamic resource allocation, and accelerated delivery.  Moving from funding project scope to funding teams is a seminal part of product centric funding.

However, a clear understanding and alignment on “Product” and “Product Portfolio” terminology is imperative before delving into the product-based funding model and financial governance.  It is often surprising to agile team members through all levels of leadership how hard it can be to all agree on what a “product” is.  We often start by getting an agreement on what a product isn’t, such as a platform or other part of the technology stack or a corporate function such as marketing.

What is a Product?

A product is designed to continuously create business value for the customer by solving their problem or providing a benefit. Products have more permanence, and are living entities that we continuously iterate to meet market needs and finally are retired when the demand for it diminishes.

On the other hand, a project is a temporary endeavor, with a clear definition of the work that needs to be delivered, within a defined budget and by a specified date in time.

Key characteristics of a Product and a Project are elaborated below:

So, what are the benefits of pivoting to a product mode?

High Performing Teams

Standing Projects up and down is Inefficient and runs the risk of disbanding teams just as they enter the norming or performing phase. Organizations often underestimate the staff onboarding costs and ramp up time. Most product-centric organizations try to keep the same people working on a product through the lifespan of the product. Overtime, these teams build the stakeholder relationships and business domain knowledge, being stable and long-lived can benefit from a long performing phase.

Maintain Strategic Focus

Projects are funded independently and investments tend to be quite scattered and fragmented. Often, this leads to executives not having enough confidence that much of their investments are committed to top strategic priorities. Moreover, it really slows the organization’s response to change in business priorities.

Product Roadmaps are aligned with business capabilities and deliver measurable business outcomes. Further, funding is continuous with frequent checkpoints, allowing to dynamically reposition investments should the business priorities change

Ability to Truly Iterate

Projects are funded in one go, the entire agreed upon scope is funded to deliver the projected benefits. These un-validated hypotheses of benefits in the business case are based on a lot of assumptions, and it is often not feasible to clarify the entire scope upfront, despite the significant investment routinely made with traditional approaches. The reality is that many projects regularly miss the mark in terms of delivering benefits, and organizations often don’t have an effective process in place to validate actual benefits post every release.

On the other hand, product funding is continuous and flow based on validated learning of short timelines. This is a truly iterative approach that allows to pivot or preserve strategy to maximize the value delivery.

Customer focused

Project teams measure success as the delivery of agreed up-front scope, on time and in budget. This often means that they get too solution focused and lose sight of whether appropriate value is being delivered to the stakeholders. There is no point in delivering the entire upfront agreed scope if it doesn’t cater to the stakeholder needs anymore.

We all work to create value for our stakeholders as well as the organization. Business outcomes allow us to define value in a measurable way, thus focusing on what matters most from the customer perspective. For product teams, success equals improvement directly related to a business outcome. Hence, rather than seeing their job as delivering a task, product teams focus on delighting and adding value for their customers (internal or external).

Knowledge Retention

Project teams ramp up quickly to build a solution over one or more releases, hand it over to an operations team in the “run” organization and are then disbanded, and the members move on to other project teams. With project teams being continually dragged onto new things, it gets very difficult to retain knowledge in legacy systems and often results in unmaintainable code, making it much harder to support such systems.

On the other hand, knowledge grows in product teams that allows team members to focus on a given business area for much longer. Overtime, these teams build strong stakeholder relationships and business domain knowledge, and can better understand the stakeholder problems and serve to their needs.

System Integrity and Continuous Improvement

Project teams are in constant pressure to deliver the agreed scope in defined timelines. This often leads to cutting corners and applying tactical fixes, increasing technical debt and neglecting long term architectural integrity in favor of short-term feature delivery. As the project team doesn’t face the long-term consequences of these tradeoffs, they are more likely to take such decisions for short-term gain. Over a period, this phenomenon compromises stability of systems, lowering quality and worsens the seed of value delivery.

On the other hand, Product teams have complete and collective ownership of the code and systems. There are no handovers, BAU or Operations team. The same team builds, runs and fixes any defects over the lifespan of the product, allowing them to evolve the system continuously and in a more sustainable manner.  This also fosters a mindset that promotes taking responsibility for their product and the decisions they are empowered to make.

Making the shift to a Product Centric Organization Model

According to a recent Gartner survey, 85% of the organizations have adopted or plans to adopt a product-centric organization model.

To enable accelerated value delivery, adaptive planning, and flexibility required to achieve the digital priorities, many organizations are shifting towards a product centric model. In a product centric model, organizations align funding & resources to product portfolios that support their key business capabilities.

A business capability is the ability of an organization to do things effectively to achieve desired business outcomes and measurable benefits. Each business capability is independent from other business capabilities and realized by combining different functions of an organization to fulfil one functionality. Example, for an FMCG, key business capabilities are often: Direct to Consumer, Wholesale and Retail.

The key primary constructs of translating Enterprise Strategy into traceable User Stories, via Features and Business Outcomes are:

• A Product Portfolio, also known as a Product Line, solely exists to fulfill its contribution toward realizing the overall enterprise strategy. Each Product line is tied to a distinct business capability with end to end accountability to deliver measurable business outcomes.

• The Portfolio Management board allocates funding across each of the Product Lines based on the importance of the business capabilities they support and the business outcomes they are expected to deliver. The Product Line budget is then split into individual product streams by the Product Line Council, which is then further split into individual feature teams by the Product Council.

• The business outcomes communicate aspects of strategic intent from the enterprise to the product line. Business outcomes are a means of concisely capturing business needs in a measurable way. Business outcomes most often require product functionality as well as supporting business activities (sales, marketing, promotions, delivery chain, etc.). The product teams work with leadership to establish measurable product outcomes tied to those business outcomes, which are then further split into Key Performance Indicators (KPIs) for each Product Feature team, who will then breakdown those features into user stories, establishing a clear line of sight from enterprise strategy to user stories.

Adaptive Funding of Products and Product Portfolios: From Annual to Quarterly Cycle

Organizing work by Products and Product Portfolios is a good starting point to accelerate the delivery of value to one’s customers. However, that enough won’t suffice if the work is still funded through projects on an annual basis.

An annual investment process simply can’t keep up with the pace of change. Under an annual planning approach, entire funding is allocated at the start of the fiscal year. Significant effort is spent upfront to create a detailed business case required to win the funding approval. Changes in stakeholder priorities or market demand often render a lot of early requirements captured in the business case as obsolete, creating a lot of waste and requiring significant rework.

Thus, to achieve their digital ambitions, enterprises must work with business and Finance partners to move beyond traditional project-centric funding models and adopt a product-centric funding model that enables rolling-wave planning, accelerated delivery of value, and validated learning to make much more informed decisions.  Moving from funding project scope to funding teams is a seminal part of product centric funding.

(Re)allocation of Funds across Product Portfolios

Initial annual funding allocations to individual product portfolios are based on un-validated hypothesis of benefits, which must be tested over the course of the year against changing priorities and proven value. The Portfolio Management Board meets on a recurring basis (Quarterly plus any market triggered event) to assess the allocation at the product-line level and reallocating funds as necessary to reflect changes to strategic enterprise priorities.

(Re)allocation of Funds within a Product Portfolio

The Product Line Council has the autonomy and the empowerment to reprioritize and reallocate funds across all products within the product line.  Each product team within a product line are allocated funds on a quarterly basis based on proven value (unless it’s the first quarter where funding is based on projected benefits). The business value is measured by hitting a set of KPIs tied to the business outcomes such as increasing revenues, reducing costs, and improving customer satisfaction. This level of decentralization in decision making is possible when an organization implements a consistent, standardized and predictable cadence to support governance, offering frequent opportunities for key stakeholders to provide input on the roadmap.

Impediments to adopt Product-based Funding Model

The shift from a project-based funding model to a product-based funding model requires a major cultural and mindset change, as different stakeholders will have different reservations about the new approach. Some of the challenges to adopt a product-based funding model include:

Business & Finance partners reluctant to cede control of budgets

Some CFOs and business leaders are reluctant to cede control of budgets. In response, they must be made to understand that the reality is that they are gaining a lot more control by not allocating the entire funding based on the un-validated hypothesis of projected benefits and with no benefits tracking in place most cases. Also, by offering them visibility into product portfolio performance on quarterly basis with the option to pivot or preserve funding strategy based on proven value and/or change in priorities, we can significantly reduce the risk of financial loss.

Product Managers lacking finance expertise to manage product budgets

Identifying Product Managers with sufficient expertise to manage large budgets is often challenging and requires significant effort and commitment from the organization to build the financial competencies.

Resistance to funding not” fully detailed” requirements or outcomes

Business partners feel a comfort factor with a detailed business case based on projected benefits, even if it is based on a lot of assumptions and uncertainty upfront. To get business partners fully on board, product leaders need to craft a pitch that provides tangible examples of how adaptive funding model leads to better business outcomes.

Requires structural changes to support product-centric organization

Most companies we work with are organized around functions. Organizational structure change is required to adopt a product-centric operation model. Organizations are reluctant to Org design changes as it can be very difficult and expensive to implement.

Parting Thoughts

We have endeavored to shed some light on a very complex topic, balancing the amount of context we can provide in a blog entry.  If you have any questions please do use the comments section below.

Joshua Barnes, CDAC | CDAI

Jeev Chugh, CDAP | CDAI