Being An Architect

I imagine a great architect to come in the darkness of night, to a beleaguered organization, perhaps accompanied with his team of architects. And the Architect will camp with the organization for a period of time, to learn what the company is all about, and to propose what can be done to promote its essence and existence.  The Architect will listen to the elders -- the company's collective wisdom, to hear the leadership's vision of what the company wants to be, the mission that the company wants to serve, and the goals and objectives in the coming years, to stay true to the mission.  In hindsight, the organization is not necessarily beleaguered. It could very well be an organization in good shape to begin with, which, perhaps, is just ready to go from "good to great" -- as our professor has pointed out earlier in the course.

Listening to the vision of elders.

Reflecting on the essence of an architect, I sometimes wonder of equivalents such as the great builders like Frank Lloyd Wright or an I.M. Pei, or a Louis Khan. Or to industry architects like Steve Jobs of Apple; or Iacocca/Sperlich for the Ford Mustang; or even FDR's New Deal architects like Hopkins and Cohen.  Visionaries who in their respective contexts, pushed the current knowledge of what is available, to create solutions at the edge of new innovations, and helped us -- or perhaps more important -- enabled us, to face the challenges, and possibly discover even new exciting opportunities.

Frank Lloyd Wright and his students. Image from the Ken Burns documentary. 

Steve Jobs with the iPod team

To be called an architect is to be a powerful force in the organization.  Never again should we mistake architects for draftsmen or modelers or the so-called "picture-makers," because that would completely miss the point.  The best architects are primarily communicators, both as keen listeners to the company aspirations and pains, as well as eloquent articulators of guidance towards future-state vision. As such, architects will effectively use these and any other instruments to communicate abstract notions of mission, strengths, weaknesses, and solutions.  The architect will communicate all of these with such force and clarity, to make everyone in the organization understand how all these solutions, all these components, and all these plans will work together -- to bring the company to future-state.

Iacocca and a famous customer and Mustang fan.

---

For the last 6 years an awards program has been sponsored by InfoWorld, Forrester Research, and the Penn State University Center for Enterprise Architecture. The Enterprise Architecture Awards recognizes the excellence of enterprise architects, and the organizations whose practice of the EA discipline has resulted in substantial benefit to the organizations which they serve. I think this is really a great idea.

There were five winners in 2015:  British Gas, Capital One, Idaho National Lab of the Department of Energy, National Grid, and Tata Communications, Ltd.  

At British Gas, the company formulated new strategic imperatives which aim to improve customer service and enable greater innovation.  To help with these strategies, the enterprise architecture practice in the company enabled a successful application rationalization program that reduced the company's application portfolio from 350 to fewer than 100, resulting in increased flexibility and reduced costs. The EA team as a result grew to be beloved, perhaps because they are seen as allies and pragmatics, with solutions that clearly show a deep understanding of the interest of both the company and its customers.

At Capital One, the Awards talk about how the EA practice adapted to the company's forward-looking business, by making the EA mission aligned with strategies for accelerated delivery of highly resilient and secure systems. At the company, EA enables the organization by leveraging technology disruptors such as microservices, cloud, and big data for the benefit of the whole organization. The EA practice facilitates culture development in the company through various activities such as awareness programs for advanced engineering practices, "hackathons", and design workshops. EA makes use of agile techniques to enable faster delivery of architecture guidance. And how EA provided transformational framework for improving technical competencies through continuous learning programs.

At the Idaho National Lab of the Department of Energy, the EA practice worked to address the grave issues of cyber security vulnerabilities, and provided a new EA execution model which they call "bi-modal" in order to clearly delineate two main EA missions or modes:  1.) Effectiveness Architecture and 2.) Innovation Architecture. Effectiveness Architecture focuses on cost effective operations that manage the risks associated with reliability, sustainability, and security. While Innovation Architecture promotes flexibility for the organization to explore solutions that can increase capacity, improve capabilities, and generate greater revenue.

At National Grid, the EA practice made its mission to fix the legacy technology estate that was unable to provide the business with the agility, insight, and flexibility it needed. EA focused on simplifying core business services and associated KPIs by focusing on core sets of technology in the areas of mobility, service-driven architecture, modern data platforms, and hybrid cloud.

Lastly, at Tata Communications, the EA team provided multiple road maps to transform the company's delivery architecture by placing strong governance mechanisms. These resulted in better, faster, and more accurate strategic design decisions, as well as cost savings achieved with the effective systems rationalization. The EA practice at Tata was clearly responsive to the company's strategy of placing greater emphasis on bundling and next-generation services.

So... Is your company and EA practice up for nomination for the 2016 awards?

A business strategy session from the movie "The Intern"

Conclusion:

It is important for enterprise architects to have models of excellence to which they can assess and calibrate their own development and growth. As winners of the EA Awards have shown, the EA discipline and practice is alive and well, and will continue to do so if architects collaborate and share the lessons learned in various practices, and also if we continue to dissect and fine-tune the essence of this practice that we have labeled "Enterprise Architecture".  The Enterprise Architects in those winning companies showed excellence in terms of responsiveness to the needs of business, mixing both innovation and effectiveness in their disciplines, going beyond "doing architecture," or beyond just being smart technical experts. They were all masters of business transformation, consistently tuned to the alignments that are needed, pulling the capability and competency gaps closer, enabling the IT organization and its resources towards delivering tangible business outcomes.

Being an architect is thus, not a simple profession. It takes a lot of wherewithal - particularly, analytical skills and the broad reference frame to understand applicable technologies;  to devise a plan that successfully aligns with the vision; and to have a certain courage to stand by that plan, and provide the enabling guidance as the plan is executed to transform the organization.

I would think that the set of skills goes beyond management. The practice of architecture truly contains a lot of art beyond the science -- embodying a truly creative force, whose powers can orchestrate all those abstractions into organizational action, to bring to fruition, very tangible business outcomes. It is like painting in broad strokes, perhaps even at the highest levels of business -- and with each stroke of the plan, possibly affecting so many parts and corners of the enterprise.

 Gartner's EA Activity Map

To be a true Architect, therefore, is to be a creatively formidable, and responsible, leader. When called to serve and wear the badge, the Architect must stand to be the organization's key communicator of the so-called vision.

/

I have learned a lot from the insights coming from the class discussions, and the blog forum has been very instrumental in making the discussions even more enjoyable. 

Thanks and all the best to your EA journey.

/ Ian.

---

Readings:

The 2015 Enterprise Architecture Awards

http://www.infoworld.com/article/2984801/enterprise-architecture/the-2015-enterprise-architecture-awards.html

Weiss, D., Rosser, B., Blanton, C.E. (2005 Oct 31). Enterprise Architecture Improves IT Planning Synergies. White Paper. Gartner Research Publications. (ID: G00130847)

/

On Gaps, Technical Debts, and Outsourcing Strategies

Earlier, we said that Enterprise Architecture is not only about technology capability development, since its mission of alignment to target business outcomes makes the business capability development the true goal. Clearly it now makes sense that EA has that larger scope.  However, in this reflection, I'd like to place the focus back on the technology side, still along EA's original primary mission of aligning technology development towards business outcomes, but more of fixing the technology capability gaps to address the organization's information needs.

When we talk of technology gaps, we can mean those which are freshly discovered and gets high priority and placement into an early current initiative; or those which have been previously discovered, but needs to wait for proper timing before they can be acted on, as part of the later initiatives. And then, there are also cases of these technology gaps which were supposed to be done as per previous IT strategy and initiatives, but the dynamics and constraints of the organization could just not pull it off, and work can only be resumed on these for later initiatives.  These are those promises of future vision that are left behind, and as of yet, are placed as technical debt.

Technical Debt At the Architectural Level
David Norton, in his Gartner blog in 2011, reports that technical debt will accumulate its worth to about a trillion dollars through 2016, i.e. a trillion dollars of development work to remove bad code, fix poor architecture, correct a badly-formed technical strategy, or simply catch up to good design and original intents. Norton adds that the pace of business and technical change combined with faster delivery methods like agile and "citizen development" (super-user/developer), will only add to the speed on technical debt accumulation.  Agile can indeed be a double-edged sword, which when done right can have the quickness to remove technical debt and stop it being introduced in the first place; but when done wrong can be a "technical debt generating machine."

If we think about it, the technical debt metaphor is really just part of the so-called gaps that we need to close to move the current state architectures to the future-state architectures that we envision for the enterprise. Certain initiatives will incur debts (work that has to be done or "paid-off" eventually), because the transition to future-state can be incremental, possibly as a needed compromise, to move from an architectural stage to another as part of a viable strategy.  And although the debt metaphor is normally expressed in the context of the detailed applications development, we can also think of these technical debts in a bigger way, particularly when debts are incurred at the architecture level, where the foundational structures are incorrect or poorly established.


Sweeping under the rug.
A few years ago, our software company was going through a major shift in technology platforms, which brought all the architects to the table, forcing everyone to bring out the technical debts.  It's amazing how these debts can grow, and can catch everyone by surprise if not properly tracked amidst the whirlwind of development activities.  The making of a monster debt is usually when the complicit cabal will sweep the "stragglers" from previous projects under the rug, where all the collective technical debt is truly waiting for the ultimate "collector". It's when folks, particularly those higher in the ladder, do not have the courage to bite the bullet, and deal with technical debts prudently, rather than just looking for the next fall guy to blame the problem when these debts collapse. The boss of my boss, has many dead bodies of previous fall guys in his closet, but eventually was himself kicked out. To be honest, it was a bit of justice long overdue.


Outsourcing: The Supposedly Easier and Logical IT Strategy
At one level or another, Ross et al argues that outsourcing should be part of every organization's strategy, and devotes the whole of chapter 7 to outsourcing, explaining how to use Enterprise Architecture to guide outsourcing.  The story of Campbell's transformation, both from a technology and business perspective, demonstrates the use of outsourcing by enabling the organization to focus their management capacities to core activities such as customer collaborations, trade promotions, R&D, and innovation -- rather than constraining their leaders with computer operations.  Consequently Campbell completely outsourced their infrastructure to IBM, who has the capabilities to address and resolve the technical debts quicker than Campbell could on their own.

Not all outsourcing will be successful, as Ross warns us of the need to apply our understanding of the enterprise's operating model, as well as use the EA framework for effective outsourcing decisions, in order to achieve the benefits that strategy can bring. And although Ross points out that an organization should not outsource the management of its architecture development, they can definitely outsource the construction of that architecture, while focusing their energies in understanding how to move the organization incrementally through the changes and architectural stages. As a final caveat, Ross notes that while the technical challenges of architecture can be outsourced and transferred to a vendor, the organization must be ready for the relationship challenges that will replace those technical challenges.

In some cases, outsourcing may not be the best option for the organization as it stands at a certain point in time. And perhaps the shared services approach will make the most sense, particularly when control is a top priority, and when said services are quite unique to the organization -- and brings a competitive advantage. However, success with the shared services approach depends on having adequate systems, skills, and capacities. If these are not on par with what an outsourcing vendor offers, it is hard for shared services to be competitive.  At any rate, EA can bring clarity for decisions, and provide options to make shared services a transition towards a full outsource paradigm.

Some Outsourcing Trends

Production workloads, and more, are getting transferred to cloud services. Amazon had the first mover advantage with the public cloud. Early adopters such as IT shops, who hopped on to the cloud first, did so with non-critical systems, i.e. testing the new environment. But in 2016, technology pundits agree that there will be more production workloads moving to the cloud, and not just on AWS. IT organizations recognize that the future of their data centers will need many platforms, so they expect to see more CIOs experiment with other major public cloud options, such as Microsoft Azure and Google Cloud Platform.

Integration challenges continue to surge.  I agree with those who observe that companies are adopting an ever larger number of emerging digital technologies, and will face an ever-larger integration challenge. From our experience with our own customers, I also see that many of the most powerful cloud technologies will require integration efforts very similar to those required to install ERP systems.  Surprisingly, but apparently a keen assessment, that most companies do not have employees capable of managing multiple emerging technology platforms, which makes it a logical strategy for these companies to outsource (or at least consult) for service integration, incident management, and change management. We can definitely expect increasing outsourcing partnerships among providers, as Ross has argued in our course book as well.

The cloud initiatives, while it can also have the "private cloud" flavor, are essentially an outsourcing paradigm because it is the external paradigm which makes the most sense when doing cloud.  This is clear to the outsourcing industry itself, which is more and more, shifting its business model to cloud delivery. Big Data handling is connected.  Not many organizations will have the kind of infrastructure that can really be optimized to handle Big Data.  Cloud allows the organization a cost-effective entry into big data benefits.

BTW, if you're still confused on why big data is such a big thing, read Mayer-Schönberger's  book on big data (book listed below).


Conclusion
Enterprise Architecture can improve IT and business alignment by integrating the EA practice with enterprise IT planning processes. By providing the clarity of alignment of future state architectures to strategies for achieving target business outcomes, EA can provide enabling guidance in formulating effective IT strategies. Moreover, as part of its methodology, the EA practice can identify the technology trends that would be strategically meaningful for the organization, determine the transition roadmaps towards innovations, and define outsourcing boundaries and strategies to quickly resolve technical debts and close the capability gaps.

EA can define the transitions needed towards an outsourcing paradigm suited to the organization's culture and operating model. Outsourcing typically will make the most sense for strategies that require fundamental change, with a high requirement for agility, and with cost reduction as a high priority. When an organization can acknowledge a vendor’s superior systems, and their advanced processes, skills, combined with capacities and the economies of scale -- the organization is not prudent not to take that strategy.



Readings:
Norton, D. (2011 Dec 04). The Ticking Time Bombing Of Technical Debt. Online Blog. Gartner Publication. Retrieved from http://blogs.gartner.com/david_norton/2011/12/04/the-ticking-time-bombing-of-technical-debt/

Overby, S. (2015 Dec 29). 10 Outsourcing Trends to Watch in 2016.  Online Article. CIO Magazine. Retrieved from http://www.cio.com/article/3018638/outsourcing/10-outsourcing-trends-to-watch-in-2016.html

Sako, M. (2010 July). Outsourcing Versus Shared Services.  Research Paper. Technology Strategy and Management, Communications of the ACM, Vol. 53 No. 7, Pages 27-29. Retrieved online from http://cacm.acm.org/magazines/2010/7/95037-outsourcing-versus-shared-services/fulltext

Mayer-Schönberger, V., Cukier, K. (2014 March 4).  Big Data: A Revolution That Will Transform How We Live, Work, and Think.  Paperback. First Mariner Books. Houghton Mifflin Harcourt Publishing, New York.

EA Metrics: Making Sense of the Score

Working with a client way back, we asked one of the managers why they have a particular metric.  He said "Weeell... we've always included this metric since I can remember...  And we have the data anyway -- so we collect it because we can."  Although to a certain extent, this appears to be valid, the answer did not leave us with a warm fuzzy, and the aftertaste definitely says there's something wrong with that response at many levels.

We can only imagine the reams of reports wasted, costing the organization a couple of million dollars a year globally. And it gave us an idea of how the culture has degenerated, dangerously warning at how success can lead to complacency, and into profligacy which may hint that this is just the tip of larger inefficiencies encumbering the company.  It is quite ironic given that the whole idea of metrics is to check for performance. And here you have the set of checking mechanisms itself to begin with, possibly broken and confused. 

I think there can always be the danger or "metric entanglements", when an abundance of metrics actually runs amok, counter to organizational success -- particularly when these metrics lack strategic context, not forward-looking, not effectively mapped towards target outcomes.  When the organization loses sight of what these metrics are for, the changing dynamics of the enterprise can leave these metrics disconnected from organizational objectives and strategies.

From what I have seen, I think it is really helpful for organizations to encourage constant reminders of what the metrics are supposed to do, and sometimes, revisit fundamental definitions in order to clarify the language, and achieve coherent thinking around metrics that truly benefits the company.

The Language of Mission, G&O's, CSF's, KPI's, Metrics, and Measures.

I found an effective discussion from Unilytics, simply showing 5 steps of formulations from Goals to Metrics, and onto Key Performance Indicators, which we identify when we address metrics selectively.  Combined with the Gartner discussions on Measurements, these notes can be helpful, and provide additional examples. Although the discussion is meant for Business Intelligence performance, I think the same essential principles apply to Enterprise Architecture as well.  The short discussion can be found on this link.

http://unilytics.com/5-steps-to-actionable-key-performance-indicators/

Measures vs. Metrics.  The first distinction we need to clear out of the air are these two terms. There can be an overlap between measures and metrics, and both can be qualitative or quantitative. However, measures are concrete, and they will usually measure one particular notion or observation. And because they are measurements, they are -- consequently and ultimately, quantitative in nature (e.g. we sold five apples). Metrics, on the other hand, describe a certain quality and require a baseline of measurement i.e. a metric uses one or more measures, (e.g. we sold five more apples than we did last year around this time).

Thus, No measures... No Metrics... No  insights.

Critical Success Factors.  When we speak of CSF's, we identify elements which are of such significance, that without its contribution to the mix, it would be difficult to even imagine success. We say "contribution to the mix" because, typically, one CSF has to work with other CSF's to make success happen.  Critical Success Factors are elements which must be accomplished or executed correctly so that an entity (such as an organization, process, project, etc.) can achieve its goals and objectives and accomplish the mission. There is a method to their discovery, and it's possible to group CSF's into hierarchies, in order to reveal relationships and identify primary driving factors.  Again, just to be sure of our language, we need to avoid the confusion between "Success Factor" and "Success Criteria",  criteria being the post-evaluation of outcome to be considered successful, while our former is something that we have pre-identifed as a contributing factor to the target outcome. To be fair, the two are quite closely related, and thus possibly why we have the usual mix-up.

The following discussions bring us back to the origins of CSF's:

Software Engineering Institute. Strategic Planning with Critical Success Factors and Future Scenarios.  http://www.sei.cmu.edu/reports/10tr037.pdf

Harvard Business Review. The CSF method. https://hbr.org/1979/03/chief-executives-define-their-own-data-needs

Key Performance Indicators.   Referring back to the Unilytic diagram earlier, it's now easy to see how the set of KPI's becomes the central tool for gauging EA's strategic performance.  From one perspective, this illustration explains why KPI's are sometimes described as quantifications of CSF's, and from another perspective, why KPI's are also described as a special selection of metrics.  KPIs are therefore quantified measurements of performance against organizational objectives. Thus, by definition and distinction, KPI's must be clearly aligned with strategies, and formulated with explicit targets or thresholds, within a certain strategic timeframe, to be an effective measurement of strategic performance.  These are essentially the SMART formulations, with an extended version called SMARTc3, (c3 = three point criteria, i.e. high, medium, low targets). 

Example:

Improve Cost to Service Level Performance for Outsourced processes, within the next 5 years from 2016, by a minimum of 10%, acceptable at 20%, and high target of 30%.

The Main Measurement Flavors.

Compliance Metrics.  The organization needs to evaluate progress towards doing things in the way it was prescribed as per organizational policy or standard, or by government or industry regulations.

Process Metrics.  An evaluation of performance and progress for improvements to processes -- whether for the business, IT, or specific to EA; is required to ensure achievement of goals and successful strategy execution. Use process metrics to evaluate business processes, establish process improvement goals, and measure progress against those goals.  Metrics formulations for processes should consider applicable constraints and limitations, while keeping aligned towards targets of business outcomes and benefits.  An effective metric will not only show evidence of success, but also indicate contributing factors to failures. From 871, I remember the exercise on Gartner's set of EA process metrics, grouped into process performance, organizational coverage, and architectural content utility.

Capacity and Workload Measures.  These transactional measures are useful to demonstrate workloads, capacity, and resource utilization. Data may include the number of transactions performed, hours expended, requests for assistance, number of people trained, etc. These can facilitate discoveries and insights into resource requirements, particularly when presented in combination with process or compliance metrics. As discussed earlier, measures are the ingredients which can be mixed in different creative ways to gain insights through metrics and KPI's.

The Challenges of Qualitative Metrics.

There are many discussions on metrics challenges which point out difficulty and expense of data collection, accuracy, timeliness, and agility issues, and interpreting and presenting the scores. We also have discussed elsewhere the misplaced use or non-use of industry benchmarks, the wrong emphasis on the past rather than being forward-looking, as well as cultural challenges that can include "gaming" the system to the point that the numbers are a joke.

But there is one side of these scoring requirements that can truly be challenging -- because these are the ones which are hard to quantify, and can only be provided through qualitative scores.  Indeed, this is the second part of Einstein's statement:  "Not everything that counts can be counted. "  The difficulty is not so much the acquisition of grade marks submitted by the various scorers in the organization, but rather the subjectivity of the grades themselves, and therefore the debatable reliability of the scores.  Experts say that this is where big data correlations can help, quantifying what at first blush may appear unrelated, but through datafied behavior can reveal patterns that translates to scores. It's definitely something to think about and explore.

Conclusion: EA Needs A Rubric

So how do we formulate metrics that are truly useful and meaningful to Enterprise Architecture?  I think we must go back and check EA's value proposition.  EA must be scored based on the quality of master plans produced; the degree of enabling guidance provided for domain architecture development towards future state vision; the robustness of the EA process to describe and size the capability gaps; the clarity and soundness of roadmaps which make organizational change manageable; and the enabling force of its models to show clear paths that help align IT capabilities and intent, with those of the business. Thus, in essence, the set of metrics for EA is based on how well the discipline enabled the business to execute on its strategies.

In many ways, a metric is really very much like a rubric. Much in the same way a set of rubrics provide a meaningful structure to a set of observations, a well defined set of metrics gives a coherent view of performance, rather than just a bunch of scores. I've read somewhere that the genius of rubrics is its whole approach to scoring i.e. the beauty coming from how performance is described rather than "evaluated." In the enlightened rubric paradigm, the point is to match the delivery to what is described as excellent performance -- in other words, the approach is normative rather than evaluative. Understanding the nuance can liberate a powerful force in the organization, which can motivate and engage the various participants towards more collaboration and success towards goals.

In the context of enterprise architecture, best practice must ensure metrics development is in place from the start, in order to set the agreements on how EA will be scored -- a clear rubric as it were, to guide the enterprise architect every step of the way, as the architect keeps his value proposition to the organization strong and undeniable.

/

Agile Governance: Keeping Sharp (and Awake)

Ross, Weill, et al, exclaim that governance is dynamic. And we can only nod our heads vigorously in agreement.  The Raytheon story tells of the fine-tuned governance model the organization had successfully put in place.  But as soon as they celebrated the accomplishment, the governance model no longer fits. When they shifted their growth strategy towards making new, and sometimes aggressive, important investments, the governance model no longer provided the support for making those decisions, i.e. arriving at decisions became an impeding challenge.

The Gartner discussions on Governance also point out that successful organizations with an EA practice must take a new approach towards EA governance. Organizations must begin by asking themselves five important questions which should guide the approach to EA governance and make assurance efforts more efficient. To achieve governance agility, it is important to know just how much governance is appropriate, what type is really needed, and what processes are in place.

The 5 Key Questions Towards Agile Governance

1. The first step in determining the appropriate scope of governance begins with the following set of questions:  What are the key decisions that support the business context and move the organization closer to meeting its objectives? Which decisions will enable the organization to meet its strategic goals?  These questions will help identify what areas need to be governed.

2. Why are these decisions important? To be competitive in the market, the business will depend on capabilities which enable the organization to execute the business strategies.  The rationale for which capabilities need to considered, and understanding why organizations need to make decisions on these is important, when agility of response to rapidly evolving demands of the market, is the only way to be in the game.  Wondering and scratching heads, while the competition understands why certain decisions matter, can leave some companies in the dust. As Gartner points out, environmental trends -- which comprise the aspects impacting the strategy, can be very useful in determining how important the strategy -- and strategy decisions, are to the business.  Understanding stakeholder viewpoints and the importance on viewpoint-related decisions will also facilitate governance agility. We were also reminded to articulate the importance of these decisions by linking EA governance to corporate and IT governance.  If the linkages for engagement have been established properly, the importance of these decisions will be better understood by business and IT.  If decision-making is properly understood by all key stakeholders, the road for architecture assurance and compliance becomes less bumpy.

3. Next, the critical question would be: Who are the best qualified individuals in the organization to make these decisions? Who does the governing?  It is not always IT, nor is it always only the business. It is the combination of both that provides the synergy that leads to competitive advantage. IT capabilities can be enablers for the development of business competencies and capabilities -- and are therefore enablers of business strategy, rather than a hindrance. Identifying the right people at the right level requires an understanding of how individuals process information and arrive at decisions.  If the organization knows why these decisions are important, it's easy to understand why they need to identify who should make those decisions.  As Gartner warns us, choosing individuals solely based on hierarchy in the organization is not always the best choice. To arrive at the best decisions in a timely agile way, the right people should be those that can synthesize the information from a keen understanding of IT and business implications. Chosen properly, these people ensure participation and buy-in,  from both the technical and non-technical sides of the organization.

4. The governance process needs to be made clear to the whole organization. How should these decisions be made? How is governance supposed to be implemented? The best processes for making decisions depend to a large extent on the organizational culture. Here, the governance style must be compatible with the culture.  Doing otherwise can lead to a highly contentious environment, can get bogged down towards inertia,  which can definitely grind slowly into grid-locks -- a state which is obviously remotely agile.

5. Governance should be adaptive and sensitive to the dynamics and challenges of the organization. When is it appropriate to make these decisions? When is governance applied? Timing is everything. The same decision could either be right or wrong depending on when it was made, and there are indeed scenarios when decisions could be made too early or too late. This is very true for decisions that need to synch with investment cycles in the organization, which perhaps will require an astute understanding of peak patterns for expenditures.  Decisions on architecture compliance should obviously be timely and synched with development stages. Governance should not be an impedance to the development schedules, and must be coordinated well with portfolio management, down to projects, in order to minimize overhead impact -- not only to schedules, but costs.

Governance Overkill brings Death to Agility.

It is possible that the organization goes overboard, adding layers of process for process sake, resulting in too much process which can stifle innovation and diminish the agility for governance.  Some organizations create so much process that the team gets bogged down in documentation and becomes distracted, losing responsiveness to the dynamics of business drivers.  Governance can be so encumbered, that the overkill can lead to "death by process", producing artifacts which no longer have actionable value, and long review processes which can truly miss the boat - so to speak, and leave members frustrated and demoralized.

When Governance itself is dead, this is what happens:

Governance Agility with an Effective Repository

A streamlined and integrated EA information repository can bring the balance between Governance and Business Agility. In today's highly dynamic business environments, there is a need to allow the business to be agile, while ensuring appropriate governance mechanisms are in place. The increasing need of business users for speed and agility also requires a higher degree of speed and agility in IT delivery that cannot be impeded by governance overkill.   Control and governance practice can both be implemented to a high degree, and still be streamlined without such overkill.  A highly integrated EA and IT project information system can promote that balance of governance with business agility, to be responsive and adaptive to what the business requires. Mechanisms of automation should be explored, and applied as much as possible, to achieve this agility. These can empower not only EA and IT practitioners, but also empower the business users, with more direct access to business-IT alignment information.

Governance Agility at the Project, Program, and Portfolio Levels.

Coming back to the earlier story of Raytheon, the need for governance is important and must be defined well to be effective -- particularly when companies grow, and even more so for those who have embraced Agile processes, in order to be responsive to the rapidly evolving challenges of the market. The article from CPrime argues that while small companies can likely get away with fairly informal governance, larger enterprises cannot function effectively without formal controls in place. From my experience with small and large-scale implementations, I strongly agree. It also makes sense that in the same way projects and initiatives benefit from being managed within a program and portfolio framework, the same way agility is achieved by aligning governance with that same framework.

Agile Governance at the Project Level.  Effective governance at the project level identifies and advocates for specific goals to be reached during each delivery iteration. It helps determine the core requirements that comprise the initial release of the project, and the criteria by which additional goals will be decided upon.

Agile Governance at the Program Level.  A program can be defined as “multiple related projects that are managed in a coordinated fashion.”  Since multiple projects may be closely interrelated, effective agile governance can often be achieved at the program level, where these multiple projects align with certain broader business objectives. At the program level, the more comprehensive strategic goals of the organization filter down to individual projects that produce tangible results or benefits. From this perspective, the program level can be the optimal placement for agile governance. Managers at the program level are in a position to understand and translate the overarching strategic goals of the organization to project managers, who may otherwise suffer from tunnel vision.

Agile Governance at the Portfolio Level.  A portfolio is a collection of programs or projects and other work, grouped together to facilitate effective management, in order to meet strategic business objectives. This level defines the broad strokes, and has the clearest view of the landscape to provide effective prioritization of all projects and initiatives. Managers working at the portfolio level are primarily concerned with organizational strategic goals, and are not concerned with details at the program or project level.  Their focus is on the general direction in which the company’s projects and programs are headed, and are primarily concerned with strategic budgets and time line. Effective Agile governance at the portfolio level allows for optimizations in terms of  time, money, and personnel. 

Conclusion.

An agile governance model can energize guidance and control for corporate processes -- and thankfully for our own sake, can also do the same for both the EA and IT practice. Good governance is a key success factor for EA to deliver real value to the organization.  The development of enterprise architecture is important, and architects can produce meaningful vision artifacts and roadmaps for transition intiatives. However, without the guidance and control for the adoption and execution of plans, the chances of success without governance is low. EA governance should work with IT governance to align with drivers set by governance at the corporate level.  Properly coordinated, and with a clear rationale for decision processes, these combined governance mechanisms can facilitate the required level of engagement, help enable for strategy execution, and keep the organization sharp and competitive -- in the context of new agile business environments. 

/

Unleashing the EA Genius with the Repository

EA work can be challenging. Too many things to capture. Too many things to validate. Too many stakeholders to make happy.  As many others have noted, I think there is a viable way to make it easier. The following reflection hopefully provides a strong case for a liberating solution.

The Many Moving Parts of EA

Alignment is such a sweet simple word, that it can be truly deceiving -- masking the complexity behind EA's genius of simplification. And although we are now moving into consensus as to what is “enterprise architecture”,  organizations will continue to interpret and emphasize various aspects of EA, leaving many other aspects possibly neglected.  And as many of our discussions and blogs have pointed out,  different technology camps will place varying scope for enterprise architecture, which only adds to the confusion.  There are indeed so many moving parts that it takes some kind of savant to be fully engaged with all aspects, something like IBM's Deep Blue or the recent Watson which (or who) won the ultimate Jeopardy season.

So far, at this point in our learning journey, we have come across requirements to clarify business context, alignments to mission, goals, and objectives; the need to understand strategy execution, operating models, maturity stages; the importance of stakeholder management and engagement, understanding their viewpoints, and expressing these through capability requirements. Moreover ,we have revisited the tools to develop and communicate future state vision, which made us re-think architecture principles, business rules, standards, and trends.  Recently, we have covered modeling techniques to bring out current-state constraints by delineating functions, modules, and the interfaces that connect these components.

Gap Analysis must be done well.

We are now, therefore, at cross-roads, continuing to find a clear set of methodologies and standards that we can apply effectively to properly execute Gaps Analysis.  Obviously, this is critical. When done without competence, the organization remains clueless on things that are missing; or perhaps know things are missing, but can't determine by how much. Indeed, the gaps and the size of the void  determine the work ahead, define the roadmaps, and how the organization charters its course.  Poor roadmaps will be at best clunky hit-and-miss affairs, and at worst case, leads the enterprise to the depths of hell and quagmire -- a place where recovery is rare.

So really, to my mind, Gaps Analysis is truly important, since the results determine which intiatives/ projects are defined, proposed, evaluated,  and undertaken. Moreover, these initiatives and projects are further assessed against others in the portfolio, to see which brings the highest value, against their level of risks. The prioritized intiatives and projects form execution strategies aligned with those at the enterprise level.

As these strategies are executed, the mechanisms of governance come into play, monitoring these initiatives and projects move through its lifecycle stages, where processes check their development, their adherence to strategies, policies, principles, and standards; and by which decisions for go/no-go, funding, and selections are made.

However, with all these EA elements to sort through, how do EA teams manage to do the required vetting and analysis?  For example, can EA confidently have answers to challenging questions such as:  How many entities are related to the notion of risk?  How many processes support Customer Service directly, and indirectly in the 2nd order? When measuring leadership capability goals, how far are we from achieving competetive status?  When we speak of capability gaps, how big exactly are the gaps? Can it be sufficiently described to be convincingly actionable? Indeed, how does EA provide these answers?

The EA repository is our friend.

The Case for the EA Repository

Given these discussions, we need to  place high significance for the EA repository and find an approach to establish an effective repository suitable for the enterprise. Moreover, we can argue the fact that the body of documentation for EA are "living documents" i.e. dynamic, and can change constantly given the many moving parts that we have discussed earlier. Given these requirements, the repository solution needs to be highly extensible, and therefore open, to accommodate and interface with new tools and EA products that the organization might want to use.  And while adaptive to several tools, the core structures defined for the repository should be standardized and selected based on customized requirements of the organization.  

The repository should be designed to be implemented as a website and should be accessible even from remote internet devices. A a central tool with expected high usage, the repository has to be  is placed in a robust database platform that can store and capture data and images from all artifacts, to include data elements from diagram models (e.g. entities, relationships, constraints, etc.),  and perhaps even include rendering information (to draw the models out).  It is important to stress the importance of developing a web-based EA repository that provides easy access to EA artifacts which can truly facilitate and enable planning and decision-making throughout the enterprise.

Establishing the Repository

Enterprise Elements LLC is a company which has done this. I checked recently but the site appeared unavailable. At any rate, they worked with the DoD before, using the repository tools that they have developed to bring in EA data elements from various tools.

http://www.enterprise-elements.com/

However, another viable option is to build a homegrown repository, customized to the needs of the organization, avoiding lock-in dependencies with a repository vendor, and having full control of its evolution. It's not terribly difficult, and can be spec'd out easily enough to be outsourced without too many issues.

The key is to find the API's from the EA tools that will expose data elements and other useful information - perhaps even rendering data, so the drawings can be rendered back from the database, outside of the original tool. This rendering capability obviously, is an extended project already.  However, for the purpose of capturing the data so it can be sliced and diced in analysis,  straightforward data capture, storage, and reporting is not hard to accomplish.

By default, Enterprise Architect stores its repository data in a .eap file. One fellow shares his techniques to extract information from Sparx's Enterprise Architect tool, and loads the extracts into his own database.

http://www.drowningintechnicaldebt.com/RoyAshbrook/archive/2013/01/28/how-to-make-ea-enterprise-architect-documentation-available-to-those.aspx

Embarcadero exposes its data via a csv export, and a reporting facility.

https://www.embarcadero.com/images/dm/technical-papers/metadata-repository-ron-lewis-2.pdf

The same way with IBM's Rational System Architect.

https://www.ibm.com/developerworks/rational/library/rational-publishing-engine-generate-compliance-documents-3/

More repository development ideas for model collaborations, versioning, and extensions are described in the following links - specific to ArchiMate discussions.

https://github.com/archimatetool/archi/wiki/Feature-requests-and-roadmap

http://www.slideshare.net/matteobusanelli/extracting-archimate-views-from-custom-ontological-ea-models

And lastly, I found this great set of discussions for Automating Enterprise Architecture Documentation, and gives a great insight on extracting EA information from SAP systems (PI).

(The PDF can be retrieved on google search: Proceedings of the Eighteenth Americas Conference on Information Systems, Seattle, Washington, August 9-12, 2012.)

Conclusion

The EA repository is an enabler for an effective EA implementation methodology. The strategic goals can easily be linked to various points in the EA Framework, tracing which EA artifacts are associated to these goals. Similar traceability can be established for stakeholder viewpoints, business processes, information flows, systems and applications, technology infrastructure components, security implementations, tools and tool evaluations, and governance workflows.

There is truly a strong case for building a robust EA repository. It is a critical central tool for any architecture development — for each domain-specific work, and even more so for enterprise architecture, which needs to have a facility that can help it integrate architecture development across all domains, as well as help go through the various dimensions that need to be validated for alignment. Lastly, this datafication of architectural elements provide the ultimate tool to fine-tune in a granular way how we measure EA, allowing enterprise archictects to have the data to show how EA impacts alignment and integration, and facilitates evidence-based reporting on EA’s contribution to the value chain.