EA 872 Week 7 Delivery approaches

Hello again! As always, thank you for reading!

My last couple of blog posts have been focused on different tools or techniques that I have used to establish support, agreement on vision, and key metrics. All of these approaches have been targeted to moving an organization or project to a future vision or state.  This week, readings on "Logical Levels" talked about creating or defining process patterns, viewing information points, and services architectures.  So, as I have done the last couple of weeks, I'm going to reach into my past and discuss another approach that I have successfully used.  We derived a lot of the data that I have written about during a week long Strategy & Planning session. When all of this is pulled together, the other artifacts get us to some of the logical views that are discussed this week. This information happens to be focused on Business Intelligence Solutions. So, it will be biased to reporting and data analysis. But I feel these approaches and techniques can be useful in any EA effort.

We would often utilize a workshop-driven approach to accelerate our client’s knowledge acquisition and planning of the process, organizational change, and capabilities necessary for planning and delivery of key initiatives. This could easily be the Future State we often discuss in EA.  Here is a diagram that better depicts this approach.

If you look back to the last couple of weeks blogs, you will see that there are a series of artifacts created that include SWOT, GQM and Project Complexity. The workshop takes this information and then works to tie this together into more logical views focused in three key areas necessary for development and ongoing execution. These are:

• Reuse Library: Contains all reusable assets, certified for use in the Application Architecture.

• Application Architecture Repository:  Software structure for each application of business intelligence & reporting solution, verified for delivery into the Deployment Architecture.

• Deployment Architecture: Technical structure for all business intelligence & reporting solutions to be designed, developed, and released into a production environment within an enterprise.

We refer to this collection as a "Service Factory Architecture" which can be depicted as such:

I could go on a deeper dive into each of these three areas, but the primary goal with this approach is to drive increasing value for business through a delivery model capable of:

• Repeatability – Increasing consistency, quality, and reliability for client value
• Maintainability – minimizing (and ultimately eliminating) critical resource dependencies and constraints
• Sustainability – managing resource allocation (internal and external) to optimize delivery
• Reusability - leveraging conventional approaches, software, and tools across multiple solution delivery projects.

This Delivery Framework is  based on the industry principles present in change management and continuous improvement methodologies, and thus its structures relate back to the ‘plan – act – measure’ paradigm.  This begins to tie into how we manage from one state to the next.  To understand more completely, here is a view of the other two fundamental aspects of this framework, organization and process.

As with the Service Factory Architecture, I could go into each of the areas in more detail and may do so at a later date. As we go deeper into each of these areas, what results are artifacts very similar to what was discussed in this week's readings, logical views of the organization and processes.

 I continue to read a lot about frameworks in class, but I sometimes feel that how to deliver within these frameworks is relatively light in detail.  A quick Google search for service delivery frameworks of IT project delivery nets very few results. It would be great to hear other approaches to this.

Thanks again! I look forward to your comments.

EA 872 Week 6 Low Hanging Fruit

Welcome back and thanks for continuing to read my postings!

These last few weeks we have discussed a lot of information on current views and future state architecture.  One of the focuses has been on the ability to justify decisions based on how it ties back to business strategy.  Last week I talked about some techniques I have used in the past that provided a set of artifacts that could be utilized across project efforts. These SWOT storyboards and GQM matrix also assist with continued buy-in and help the teams tie back to business strategy.  One thing I have found missing from these discussions and readings is "where to start?".  We often hear the term "low hanging fruit" but what is it and how do you find this fruit? This is a question I often had when working with different customers. So my team and I came up with an approach that we found quite useful and delivered a metric we could use to assess the complexity of a proposed effort.

This project complexity effort was the key to project alignment, and solution delivery.  It seems to me that this could also be useful in determining both where to start and the extent of the gaps in getting to a particular future vision. Project Complexity Assessment is the process of determining a specific project’s likely complexity.  It rates a project’s complexity by assessing the project’s anticipated requirements complexity against its anticipated environment complexity. It then goes on to identify the most likely classification by establishing a complexity type for early estimation and planning purposes. This helps ensure effective expectation management from the very early stages of project inception.  This also allows one to find those "low hanging fruits."  This image represents the different levels of complexity.

Once you have determined the different project type, it is then easy to present this in a graph. This demonstrates which complexity type the project best fits and also maps the project’s affinity for both requirements and environment complexity.

There are certainly many articles and books out there about project complexity. This one on Amazon
http://www.amazon.com/Project-Complexity-Assessment-ebook/dp/B00C2HXX58/
is a result of research from the International Center for Complex Project Managment located here
https://iccpm.com/content/complexity-assessment-tool.  To me it appears that a lot of this information is just focused on the project vs how it ties into the overall Business Architecture or EA.

Once again these are just some techniques I have used effectively in the past. I believe they can add value in the EA process by potentially identifying the least complex place to start. In turn, this can offer the greatest chance of success in the shortest amount of time and as a result, add credibility to the EA team.

Please let me know your thoughts.

Thanks for reading!

EA 872 Week 5 Getting on the same page

Hello again and welcome to my weekly blog. If you are returning, thanks for coming back! If this is your first time, thanks for checking it out!

This week's readings have been about understanding the business context. This topic got me thinking about many of my past experiences and how often this lack of understanding has torpedoed a project or initiative.  As I stated in my week three post, I have often witnessed the need to build a strong team and adopt a shared environment of people, processes, and tools for project success within most of my customers.  This building and adoption process has to start with a common understanding.

I was reading the Gartner document (G00142111) "Building a 'Fast-Path' Common Requirements Vision" and in reading it, I again went back to past experiences. While I do not disagree with the content of the document, I wonder if there is not a pre-process to this CRV effort that can accelerate this type of deliverable and allow the team to get to a common understanding quickly in any conversation?

I have found that two, maybe dated, techniques when combined and tweaked a little can provide an overall understanding that can drive the CRV. These two techniques are a SWOT analysis followed by a Goal, Question, Metric (GQM) exercise. I know SWOT is not pretty, but I have adapted this into an approach that works well. I used colored sticky cards to solicit anonymous responses to each SWOT lane.

• Strengths      = GREEN
• Weakness     = YELLOW
• Opportunity   = BLUE
• Threats         = RED

From there I arrange the cards on the wall during group discussion for their consideration and feedback. With these flows, I establish a series of Critical Success Factors (CSFs) that evolve into a storyboard. Here is an example:

The next day these CFS storyboards would be laid out on the wall of the meeting room. This visual provides an easy to read view of these CSF and the stimulus for each. A digital version is created to store and distribute. This artifact is then easily recalled when one needs to come back to it.

Now that we have this level of consensus, we would begin GQM sessions.

Per, Basili, V. , et. al. The Goal Question Metric Approach, GQM is
“A technique that is based on the assumption that for an organization to measure in a purposeful way it must first specify the goals for itself and its projects, then it must trace those goals to the data that are intended to define those goals operationally, and finally provide a framework for interpreting the data with respect to the stated goals.”  

The GQM process allows one to link conceptual goals back to the SWOT and then operational level questions to quantitative data or metrics. This is then used to measure success and failure.

I could probably write a blog on just this technique and the success we have had using it, but I want to circle back to my original point. Doing an exercise like this sets a series of high-level strategic goals and objectives that a management or executive team can buy in on. This further helps EA with their future vision planning and migration efforts because it also provides a set of metrics, that are agreed upon, to track goal achievement. I would propose that that one would benefit from having these defined objectives and metrics to work with while building out the CRV.

Let me know what you think or if I am off base here. This is just an approach I have used with successes, and I would like to hear how others have built a consensus in their efforts.

EA 872 Week 4 It's all about the people!

Hello again!

This week has been a wild one! I am jumping into class team assignments, which are always a little tricky at the start. One has to get organized and establish some level of communication with the team, while never meeting any of them face to face!  For me, this tends to be easy as I telecommute and work with customers/sites remotely a majority of the time.  Given this, I started thinking about how it might affect the other team members.  Are they used to working with remote teams in their working environments or are they more comfortable face to face? My guess is that it is probably a mix and also dependent on the culture of their organization. As I was thinking through this, I thought I might as well write about culture and the impact on EA this week.

To start with, how does one define culture? Or more precisely, how is organizational culture defined? The Business Dictionary states that it is "The values and behaviors that contribute to the unique social and psychological environment of an organization."
Read more: http://www.businessdictionary.com/definition/organizational-culture.html#ixzz3zE2OAIrA

I would say that organizational culture is shared thoughts and actions. It is these values and beliefs that tend to govern how people act in an organization. Given that this is a reflection of the business, there can be subcultures within a working business unit or team or even within a LOB.  Take a minute and think about the different groups within your organization. Do you all have the same goals and value in the workplace? Maybe, but probably not.  Since every organization and team is different, one of the first things we, as EA practitioners, need to identify is the culture and the best way to interact within the cultural boundaries of that group or team.  I am sure you have heard the saying "You catch more flies with honey than vinegar"  Well the same theory applies to starting your EA initiative. If you are considered an outsider, getting anything accomplished is going to be a challenge. The best way to come across as understanding or "one of us" is first to understand the culture of the group you are going to be engaging.  If you do not do this first, then you risk all of the team's EA efforts will be for naught.  Don't get me wrong, I think there is tremendous value in all the artifacts that are produced but remember, EA is about transformation. If the organization, LOB, or team is not "culturally" ready to accept the transformation effort, then the EA effort is headed towards failure.

This may seem like a heavy-handed statement to some of you. However, the Gartner article "Psychology May Hold Key to Successful Enterprise Architecture" from December 2005 by Robert A. Handler illustrates this point. Mr. Handler explicitly states that " Failure to address the human aspects of EA leads to EA failure." The problem is not getting the data, process, or state defined correctly. It is not about anything technical. It is about understanding people, at least, that can become the single biggest point of failure. Addressing the people issues means understanding the culture. When you do that, you will better understand how to be viewed as "one of the team" and that, in my opinion, will direct you towards success in your EA initiative.

Have you ever experienced an issue with culture and your EA efforts? If so how did it affect your initiative or project?

Thanks for stopping by and taking the time to read!