E-government Trends, Practices and Benefits

The question for public sector organizations is no longer “Should we?” Now it is “What is the Best Way …?

E-government, the web-based online delivery of government services to its constituents, is the norm at all levels – federal, provincial/state, county and municipal – in developed countries. In developing countries, it is even becoming more achievable. But is this just for external services?

Follow this link to read our latest article

Don’t Call It EA if It Isn’t EA! – Atlanta ITARC Event

Most organizations that claim to have an “enterprise” architecture practice are really only doing “IT” architecture (ITA).    What leads us to say that?  Our research shows that most organizations have limited their scope to include only IT elements like infrastructure, data and applications.  That’s OK in and of itself and it is a step up for many organizations, but that’s not EA.  Most  definitions of EA define it as creating a business strategy driven future state for the enterprise.   To achieve that goal, EA must include Business Architecture. 

In a keynote presentation at the upcoming IASA ITARC Atlanta Event titled “Don’t Call It EA if It Isn’t EA!: Moving from IT Architecture to Enterprise Architecture”, Tim and I will continue the discussion he began in his blog entry last year, one of our most read and most commented entries.   We plan to explain the rationale behind this statement and share a few tips with attendees on steps they can take to move to a more fully realized EA practice.

If you are in Atlanta and plan to attend, please let us know.  We’ll be available to discuss  ideas with any organization interested in moving into business-oriented EA. 

The International Association of Software Architects (IASA) is the premier association focused on the architecture profession through the advancement of best practices and education while delivering programs and services to IT architects of all levels around the world.  The IT Architect Regional Conference is the first event in Minnesota to address the pressing needs of IT architects today. There are 12 seminars and two tracks separated by specialty: Enterprise and Fundamentals. Architects of all levels can take their skills to the next level.

Webinar Replay – The State of EA: Is 2010 The Transitional Year?

In my role as Editor-in-Chief  of Architecture and Governance I recently had the opportunity to discuss the near-term future of EA with my fellow analyst and colleague-in-EA, Alex Cullen of Forrester Research.  During the webinar we discussed topics ranging from executive perceptions about EA to specifics on how organizations approached EA. 

Consistent with EAdirections research and our client experience I find that organizational perceptions and biases about EA can span a wide range.  Each company and even each person/role within a company can have a different take on what EA is, what it does, how it influences their organization and the value it brings. Implementation models vary accordingly.  

The good news is that there is almost always an improvement path available for any baseline set of perceptions and biases.  The key is to perform a thorough diagnostic and create an improvement plan customized to the mix present in the organization.  For those organizations that are ready, this is the year to step up to embrace business and information architecture.  It is worth noting that doing so isn’t just an exercise in building more, or better or different models.  Progress in improving the reach and impact of the EA program is a trust building exercise.  For those that are not yet able to immediately integrate BA and IA into their EA approach, the EA team members should use this year to expand their business acumen and to build a stronger relationships with key business side personnel.  For those teams that are unable to reach directly into the business, they must earn enough trust from the IT executives so that they will provide the necessary introductions.  Building the trust, and demonstrating value, is a multi-dimensional activity.  With patience and a willingness to experiment, many organizations can end 2010 further ahead than where they started the year.

A replay of the webinar is available on the Architecture and Governance website.

What Every EA Leader MUST DO – This Month!”

Now that everyone is back from the holidays, relaxed and enthusiastic, it is a good time to take a look forward and update your EA program’s objectives for the new year.  In our experience, most organizations have a very short window to accomplish this.  It doesn’t take long before the enthusiasm and vision for the future is replaced by the urgency and narrowness of the day.  Since creating a coherent future target-state view is the core idea that drives what the EA program does for the organization, it makes sense to use this moment of clarity to apply that same concept directly to the EA program itself.  Doing so should drive the evolution of your EA program throughout this year and into the next.

Begin by answering a few simple (OK, not so simple) questions: What would you like your EA program to look like a year from now?  Two or three years?  How would you like it to work?  Who needs to be engaged? How are we going to create value to our organizations?  Those are your goals, driven by your vision. These are just a few of the many questions to be answered before jumping in and creating detailed work plans.  It has to drive you to achieve your idea of what a smoothly running program should be and to the level of value delivery you want for your organization. 

Only then can you lay out the granular steps along the path to get there.  Those become the objectives.  This exercise doesn’t have to be hard.  It doesn’t have to be an exhaustive and thorough definition of tasks and highly detailed sub-tasks, with explicit milestones and work allocation down to the hour.   Watch out to not fall into that trap.  Many organizations expect it, but a project plan with that level of detail often becomes a burden that inhibits EA evolution instead of enabling it.  There are many reasons why EA isn’t well-suited to that level of detailed planning, many of which are unique to a particular organization.  Call us if you are interested in exploring those reasons and why they may apply to your organization.   In all cases, though, the continuous improvement of an EA program does require a thoughtful and meaningful planning activity.  What’s really important is to build a plan to a level of detail that supports your long term objectives balanced with more immediate value opportunities.

Here are a few examples of what our clients are planning for the year:

• Expand the reach of the EA program within the organization.  Using a variety of tactics that include active recruiting, more effective personal networking, public relations activities, etc. it is important that a larger community of individuals contribute content and ideas and then, indirectly, begin to see the value in the work that the EA group performs.  An important note – “teaching” people about EA is less important than involving them in EA activities.
• Enhance governance bodies and processes to include a higher-level, cross-organizational perspective.  Too often, EA is buried too deeply into narrow, infrastructure concerns within IT.  Will business people care about things like network/integration topography choices and standards taxonomies?  Probably not, so you have to work in areas that they really will care.
• Expand the scope of EA.  With some recent nudging, the best EA groups have pushed into the business domains, to take into account the full holistic breadth of enterprise concerns, particularly business, information architectures and application portfolios.
• Balance the workload between strategic, future state development and align with current state priorities.  Our clients are either facing major initiatives (ERP implementations, major business process transformation) or economic pressure causing significant budget and resource constraints or both.  They need to balance strategy work with contributions to efforts with immediate results.

Objective setting isn’t easy.  You have to pick the “right” objectives.  Then you have to determine the right order, and to what degree, to apply them.  An “EA Capabilities Assessment” is a helpful place to start.  Unlike an “EA Maturity Assessment”, if is actionable and can directly reveal your strengths and what weaknesses you must overcome.   Doing full-year objective setting well requires a combination of insight into organizational dynamics, understanding what your resources are capable of, and how much change your organization can tolerate.   This is one place where our experience can help.  As you think about the coming year, contact us.  We’ll be happy to discuss approaches that make sense for you and your organization and give you more insight into what is achievable.

Assessing EA Maturity isn’t all that helpful – Here’s a Better Approach

Most current discussions on EA Maturity focus on backward-looking metrics and score them based on levels that are similar to the Capability Maturity Model (CMM) process improvement system developed by the Systems Engineering Institute at Carnegie Mellon University.  Over the past several years we have started to develop a different opinion about using CMM-type assessments for enterprise architecture processes.  Here’s why:

1.       CMM was originally developed for project-level systems engineering capabilities. While some of the concepts are applicable to an enterprise-level planning process, the measures of success are not. Systems engineering is more tangible such that improved process maturity results in more successful outcomes. The same is generally not true of EA.

2.       After many years of experience conducting CMM-like assessments, it became clear that the exercise of collecting the responses to questionnaires aimed at rating EA capability maturity on a scale of 1 to 5 rarely resulted in any kind of consensus on levels of maturity.  That exercise usually led to some very valuable discussions, but the rating itself was far too subjective and inaccurate.

3.       The measure of maturity itself tends to rise with age; however, the outcomes may or may not be improving as maturity increases. 

For most organizations  it is better to accept the subjective nature of EA and assess the capabilities of an EA program, not its maturity.  The goal is to identify how effective the program is within the organization.  The categories are similar to the ones that are traditionally seen in EA maturity, but adjusted to measure against a scale ranging from “significantly inhibits effectiveness” to “significantly enables effectiveness”. 

This type of assessment is a step forward in helping an EA team to better understand its opportunities for improvement, the obstacles to overcome and its leverageable strengths.  The best measure of success is still going to be the impact on shareholder value.  Being effective is a surer path to increasing shareholder value than being mature.

Tim speaking on BA Language at The Open Group Seattle

I will be speaking at the The Open Group Architecture Practitioner’s Conference in Seattle, WA during Day 2 of the  event at the Grand Hyatt Seattle, February 1-5, 2010.  

My presentation during the plenary session on Tuesday morning is entitled “Architecting the Business is Different than Architecting IT” and the session description and the rest of the event agenda and information is available at the event website.

I am looking forward to continuing the conversations around the maturation of EA into the areas of business architecture and information architecture at the event.  Let me know if you will be attending.  And please find me in the lobby, at a reception or after my presentation if you are there.

IASA “IT Architect Regional Conference” in Austin – George Paras Presenting

“Enterprise Architecture (EA) is an immature discipline and possibly getting even more immature.  As the scope of EA extends beyond the areas that IT-centric efforts are prepared for (data, app, infrastructure), the competency, credibility and effectiveness of an EA team may decrease.  However, there are a variety of ways to increase these characteristics for EA teams, regardless of the stage of maturity in which you may find yourself. “

That is the theme of a presentation, entitled “EA Profession: What’s Changing and What’s Not?”,  I will deliver at the upcoming IASA ITARC event in Austin on Thursday, February 4.   The discussion will feature a lively discussion about my assessment on the state of the EA profession, what I see going on in the industry that helps and hinders the evolution of the EA profession, and what else to expect in the future.

If you are in Austin and plan to attend, please let me know.  I’m always interested in talking with other enterprise architects, those that aspire to the role, and IT Leaders interested in having an EA function in their organization.   There will be plenty of opportunities for discussion and Q&A, including at an evening reception.

The International Association of Software Architects (IASA) is the premier association focused on the architecture profession through the advancement of best practices and education while delivering programs and services to IT architects of all levels around the world.  The IT Architect Regional Conference is the first event in Minnesota to address the pressing needs of IT architects today. There are 12 seminars and two tracks separated by specialty: Enterprise and Fundamentals. Architects of all levels can take their skills to the next level.