Coherency Management

Gary Doucet is the Chief Architect of the Federal Government in Canada. He is serving a two-year term as Vice President of a|EA International and is the past president of the Canadian Chapter. Gary came to EA after nearly twenty years with ICT, doing everything from programming to project management. He got serious about EA when he came to the federal government in 2003 to revitalize the architecture program, which had directed most of its energy supporting Canada’s very successful GOL (Government On Line) program. He reports directly to the Federal CIO in the Treasury Board Secretariat (TBS), which for those of you that don’t know is quite similar to the U.S. Office of Management and Budget.

JEA: Gary, how and why did you become interested in EA?
Doucet: I first came across EA when searching for a good way to contextualize some of the large solution architectures I was leading. When the EA ’story’ was explained to me, I was hooked on EA’s potential. Interestingly enough, it was the Federal governments ‘Federated Architecture Program’ that served as the real impetus for learning EA because it was a requirement in a major procurement. When I came to the federal government five years ago I was literally steeped in Business Architecture for several months because that was the key area of development at the time. In fact, this was the first time I saw EA being applied by business/program people to solve business design issue. There were, in fact, few IT people in the room. Since then, my interest is EA and belief that it can really change things has grown steadily.

JEA: What is the current state of EA in the Government of Canada?
Doucet: The story is mixed. In some ways we are leading in truly remarkable ways while in others we would look like we are lagging badly. The Federated Architecture Program provided some very strong guidance eight years ago with the information on domain teams, Architecture Review Board, Common Requirements Vision, principles and similar. These were implemented to varying degrees in departments and central agencies. As part of GOL, the CIO Branch developed BTEP (Business Transformation Enablement Program), which provides departments and agencies tools and methods to support strategic planning, strategic design and transformation at the business level. It should be noted that BTEP is really the next version of the Federated Architecture Program but with a name like that they couldn’t get any business people to participate.
We haven’t mandated any of the EA program yet, we still operate in the realm of guidance and best practices but there is a story here worth knowing before one dismisses the maturity of the EA program. With our BTEP experience we’ve begun to realize that conventional ways to mandate and measure EA implementation can prevent us from breaking through on the business side. We’ve adopted a strategy of working with key management process owners to ensure their policy instruments contribute to an overall EA. For example, we’ve developed normative models for Internal services which are now part of the annual budget process and will be expressed annually. So, EA might not be mandatory, but budget processes certainly are, and those will be well architected. I will say this about our program, and it’s ironic in a way. We’ve dedicated so much effort to supporting the business focus of EA that our technology friends are the underserved, if I was to measure the amount of time we spend in different activities.
The full story for EA in the federal government is more involved than can be fully covered in a interview, but we are very busy supporting key projects, developing critical tools and methods and working with key management process owners to ensure the Government of Canada’s Enterprise Architecture becomes, first well understood and secondly, well formed. With this, I believe we will contribute to Government of Canada’s effectiveness and efficiency in ways people never thought possible.

JEA: What is your role as the senior enterprise architect in the Canadian Government?
Doucet: My role, as Chief Architect in the Treasury Board of Canada Secretariat, is evolving, with the discipline itself. Currently, it breaks down into three major areas:
•    Support Key Projects. EA, in any form or application, can benefit all projects. In concert with the CIO, we dedicate resources to help the key transformations of the day. We apply our tools and methods to help with Business Design (from policy coherence to process optimization), information design, application and technology design. In some cases, we bring facilitation techniques, in others we might apply some guidance on SOA and some times we just ‘wash windows’. This is my euphemism for doing whatever the Project manager needs, in order to be successful. Hopefully, we apply the critical things from an EA perspective but we operate with one ‘prime directive’ as it were, that is, help the project. I have no interest is having EA tools applied correctly on a project that fails.

•    Alignment and Interoperability. How well the various parts of our enterprise function together can dramatically affect the success of any organization. We certainly believe this at the technology level and are investing heavily on solving this issue but I believe alignment and interoperability are even more critical at the business level. For example, our policies should be mutually reinforcing, our processes should integrate seamlessly and our business purposes should be aligned. These things may seem obvious but are very difficult to achieve in very large governments. So we work to develop a common language for business people (i.e. GSRM – Governments of Canada Strategic reference Model) and techniques to implement change that is aligned. Right now, we are developing a comprehensive set of alignment assessment tools that can systematically indicate the level to which a project (or function) is aligned to other projects (or functions). We are looking at alignment from the viewpoints of Strategy, Design, Capacity, Logistics, Compliance and method. As these prove themselves out we’ll role them in to some of our management and oversight processes and then all government departments for self-assessment. In some ways, this strategy represents a different form of the traditional Architecture Review Board. In some cases we also work with the various communities to identify or develop emerging best practices in enterprise architecture or of EA interest (like a new emerging model for citizen centric strategic design). Interestingly enough SOA (Service Oriented Architecture), an architectural model predominate in the technology space, has very good possibilities to help with Alignment and Interoperability at the business level. We’ve developed some guidance that says; rather that confining SOA to loosely coupled technical services looking at it to also loosely couple your business services. That is, think of each service with its own fully expressed enterprise architecture and the ability to operate in different contexts. (e.g., An Invoice Reconciliation Service in one department can easily serve other departments or at the very least easily interoperate with connected business processes). We also lead a standards program, which supports policy centers in the creation of policy instruments needing a specification of a detailed nature. We liaison with national and international standard organizations to make sure our standards stay in sync in that regard and that Canada’s participation in standards bodies is coordinated.

•    Develop the Discipline and the Community. Enterprise Architecture is still relatively young as a profession so it is a prime focus for us to develop the discipline and its application in the government of Canada. This involves developing the discipline itself as well as the practitioners across the Government of Canada. Some of the ideas, tools and methods we’ve developed are still under-promoted but this is somewhat intentional at the moment. Our approach to EA represents a large increase in the number and types of communities that will become active with EA so we’ve got to pace ourselves to ensure the tools we develop are properly tested and proven and that we can provide the correct amount of support for the guidance we are publishing. We keep an eye out for the tipping point where the community will be self-sustaining but our approaches are very new and still require a fair degree of close support. We also develop awareness through conferences, Webinars, white papers, and policy guidance. These are traditional approaches but what is different for us is our belief that several other communities have key responsibilities with regard to the Enterprise Architecture for the GC. With this in mind, communities like the Chief (or Senior) Financial Officers, HR management; Policy, Audit, Evaluations, etc become quite an active part of the overall EA process. In fact, in Canada, it was the CFO community that reviewed, revised and finally approved the Reference Model for Internal Services. These models were developed with the leadership the EAS Division and will allow the expression of what we do in consistent (and well architected) manner as part of the annual budget process. So, our community just became VERY large. However, the core of the community is not the Financial, HR or other business line experts. The core practitioners are the classic EA experts that understand the complexities and intricacies of normative models, viewpoints, views, etc. These are the ‘Scientists’ of our shop and they ensure the rigor of our architecture tools, methods and our overall results. Getting reengaged with this community is also evolving at a steady pace since most of the effort in recent years has been the development of the assets and the engagement of the nontraditional communities in the sense of applied architecture. In summary I would say we have a simple strategy:

• Help Projects by applying EA (and washing windows where need be).
• Develop new EA tools, methods, and models in these projects.
• Harvest the projects tools and imbed them in existing management processes.

JEA: You’ve highlighted some differences in how EA is practiced in the Government of Canada from other areas of the world, are there other notable differences?
Doucet: I think I’ve covered the major areas of difference but I should make special note of our multi-jurisdictional approach. The Reference Models we use were originally developed in the municipalities and then provinces before the federal government even understood their power. But we did and now we are establishing a ‘pan-Canadian multi-jurisdictional’ governance over the reference models. The CIO’s and Service Delivery leaders of Provinces, Municipalities (represented by associations) and the federal government meet regularly and will guide the management of the unified set of reference models. I think we are lucky to have such broad participation in the development and management of these normative models.
Before anyone thinks it’s all done, I need to emphasize that we are still relatively early in the implementation of EA in the way I’ve described. The Reference Models will eventually have to make their way into literally dozens of policy centers. Getting the budget office to partially implement some of these models was significant but I would argue we are only 1-2 percent of the way down this road.

JEA: If you could harmonize how EA is practiced throughout the world, what would some of the foundational standards be?
Doucet: This is something we discussed for a few years among some of the federal EA leaders. It is ironic that a discipline built on the ideals of structure, standardizations and normative models can’t agree much more than Zachman’s original model. Even then the debate begins on how to use it effectively. I think we need some governance … and at the international level. I also think it would be a novel idea to develop an Enterprise Architecture for an organization which settles the standards of Enterprise Architecture. Once we know the What, How, Where, When, Who, and Why at the contextual level we can start to design & build that organization. I am talking about this in a way that accommodates the way we look at EA here. That is, as an intrinsic part of many other functions such as the CFO, HR and Corporate Service functions overall. We’ve just started to do some of this here by setting up the organization for managing reference models at the pan-Canadian level. We’ll have the governance well set up before we attempt to debate the models themselves. Once the governance is in place then we’ll build up the list of standards and establish the foundation for sharing and interoperability across the governments of Canada.

JEA: What was your most enjoyable EA project and why was it so?
Doucet: The number of EA projects is quite small. These would be ones where the business objective of the project is to add to or change the EA body of work itself. The core science if you will. I find some of these projects very interesting; they really work the grey matter. Like the time my team was developing the foundation models to underpin our reference models or the development of extensions to UMM to support the modeling of government processes using the GSRM. Those were very interesting. However, the projects where EA is being used to support projects with business objectives are my most favorite. I don’t get to go deep on these much but my favorites are the ones where real change is produced … change that my friends and family might even notice. Maybe it’s the business architecture done for small business resulting is streamlined services there, or the developing of service models to improve serviced delivery for seniors. Recently, the EA team helped develop ideas for improving our delivery of Grants and Contributions. This was interesting because of the benefit it can have.

JEA: What was your least enjoyable EA project and why was it so?
Doucet: There are a few types of engagements that I find disappointing because they occur where EA is misunderstood and we lose and opportunity to improve things. For example:
•    I might get asked to lead a project that calls for lead technical or Systems Architect. The confusion here is that people think EA is technology architecture for the enterprise.
•    Secondly, we might get asked to participate in a project where EA is being used to ‘capture’ the business design only and we have no ability to affect the business design. Don’t get me wrong, having the IT aligned to the business is very useful and often enough to ensure significant ROI. But sometimes the business, services, or processes are not aligned or optimized and our tools are not applied to that problem. It’s like paving the cow path.
•    The third class of project that I find least enjoyable is when expectations are poorly managed and the EA products aren’t what are required. The analogy I use is to think of a car company. If I asked a Chief Enterprise Architect to do me up an Enterprise Architecture for a car company, I would expect to see architecture for the organization such as org design with divisions for research, design, engineering, production, corporate services, etc along with process models, strategies, and business plans. Once the organization was stood up based on that architecture we would press the giant ‘GO’ button and the enterprise would start to work and execute as designed. Eventually, a car would be produced for sale.

Here’s the problem: People that sometimes ask for an EA are really looking for well-designed cars, and not well-designed car companies. For example, we dedicated quite a bit of time towards a massive organizational change project. The key products for us were the Business Architecture ones. There were some very innovative approaches to overcoming the cultural barriers to change and the siloed organizational inertia. When we presented the results, Senior Executives were disappointed. They were looking for technical drawings showing information flows and streamlined systems. Expectation management is obviously a critical success factor. Even though we know that, we underestimated the strongly held belief that EA is about technology. So even when we said Business Architecture, they heard Systems Architecture for the Business. All of these issues have to deal with our inability to properly explain the value of Enterprise Architecture beyond Business-IT alignment. Once we get our messages straight then these issues should become less problematic.

JEA: What advice would you give to someone who is just starting an EA career?
Doucet: Here are some of the key items:
•    Get educated – there are plenty of strong EA courses out there but look for the ones promoting business architecture for business people.
•    Get a buddy – find a mentor that is successful in your organization or somewhere close.
•    Get focused – you must ensure that your goal is the improved enterprise, not the improved architecture. Unapplied architecture is the great embarrassment of our profession.

JEA: What advice would you give to someone who leads an EA practice?
Doucet: Important items include:
•    Get Business Oriented – expand your circle of architects to the owners of the key descriptive processes, they will play a large part in the ever greening of your EA. Be prepared to spend less and less time discussing IT.
•    Get Real – avoid boiling the ocean and don’t think that your mission is to build the ‘as-is’, ‘to-be’ and strategy for change in one fell swoop. Think incremental improvement!
•    Help the Project – harvest the result.
•    Get active in the community – leaders of EA programs are all sharing the same types of issues. Join with others and share your ideas, questions and maybe get some ideas.

JEA: Any final thoughts?
Doucet: Be prepared for the EA shift. With the changes being described in “Coherency Management” there will be a subtle shift in how we must talk about and apply EA. It will help (I believe) EA to ultimately become a discipline that improves all parts of the enterprise not only systems architecture.