EA Tips – Style AND Substance

For an EA practice to be effective EA leaders must pay attention to both the “style” of how their team operates and the “substance” of the work they produce. While that guidance isn’t new, in practice I often find that many leaders don’t have the balance quite right. It is worth revisiting as a general EA Tip.

First, what do I mean by “style” and by ‘substance”? (note: I chose those words because it sounded like a catchy blog title) For the sake of this article, I define “substance” to be the “work product” of the team as viewed by EA consumers wanting hard deliverables like frameworks, models, standards, roadmaps, strategy papers, and other related content. “Style” refers to “how” the team works with the rest of the organization in creating and utilizing their content: engaging business and IT leadership, fostering a collaborative environment; choosing communications vehicles, the words they use, and the “posture” of how they present themselves to the rest of the organization.

Many EA teams disproportionately direct more effort to the substance of the work than to building a sense of ownership and socializing the desired changes. In essence, they under serve the “style” elements. Granted, substance is critical. No matter how good the soft skills are or how convincing the leaders are, if the content isn’t solid then nobody will follow. But what is more surprising to many teams is that even the most elegant and perfect deliverables often don’t have impact. Why? – Because the team hasn’t positioned the larger workforce to embrace enterprise architecture content and to use it in their day to day work.

Improving the EA team’s style is often where we spend time with clients, specifically working on the “art” of practicing EA. Though many EA’s wish there was a methodological approach to these softer elements, there really isn’t one that works in all cases. People, perspectives, culture, and individual skills vary widely from organization to organization. One approach is to look to lessons learned from the organizational change management discipline, particularly as they apply to driving change across and down into an organization. There are tried and true techniques for preparing organizations for change, conducting education and awareness campaigns, gaining support and participation, and communicating effectively through a variety of different channels. After all, one of the valuable outcomes from EA is helping an organization move from an emphasis on tactical execution and silo behaviors to one that includes a larger, enterprise-wide strategic element. Substance is great, but style really does matter.

Things EA’s Should Think About – External Collaboration

One of the many interesting outcomes of today’s business climate is the increasing variety of new business partnerships. Traditional boundaries between organizations are giving way to innovative and creative relationships, driven by a combination of necessity and opportunity. Cross-company information exchange and collaboration is the central success component.

Organizations are discovering that there is often more to implementing these partnerships than is apparent at the outset, and the issues multiply with each new relationship. For example, “How can we effectively share information and collaborate with partners while protecting business confidentiality and adhering to regulatory concerns”? Those are just two among many important considerations. Issues intrinsic to external collaboration have far-reaching implications. Identifying and addressing them is tailor-made to the broad, cross-enterprise, cross-domain perspective and analyses that an EA group can bring to the table.

Many organizations are discovering that the volume of requests to share information is increasing with each new business partnership, as is the type of information exchanged. Increasingly, they are seeing demand for bi-directional collaborative interactions, in near real-time, and with a frequency that makes it difficult to respond in time to address the market opportunity. Furthermore, these collaboration requirements are contextual and don’t always fit into a standardized approach. Not only will different companies have different needs, but it is likely that there will be many different models even within a single company based on the type of partnership and the participating departments. Some cross-organization collaborative examples we have seen include legal negotiations, multi-company engineering activities, resource scheduling /provisioning, joint marketing initiatives, barter arrangements that include trading excess production capacity for a right to access an organization’s client base in a foreign market, and many other variations.

It is likely that a single standard solution cannot address the full range of scenarios an organization might encounter. The EA group should work to raise the visibility of the most pertinent issues. They should guide the creation of a general framework, including a set of rules, principles and approaches that can address them. Here are just a few of the questions organizations we work with are beginning to ask:

• What is the business vision for partnerships? How will they grow and evolve? Where do they fit in our overall enterprise model? Which business processes, business functions and information areas are involved? What is the business value to enabling these partnerships?
• What confidentiality, proprietary, legal and regulatory issues are relevant? What other business risks are in play?
• What patterns of external collaboration exist with potential partners? Are there standardized business patterns and collaboration models that will broadly satisfy business need?
• How should external collaboration integrate with our own internal collaboration models and enabling infrastructure? Should it? Do we grant access to external parties?
• How do we protect our proprietary and confidential information from being intentionally or accidentally passed on to other parties? How do we protect theirs? Do we restrict unauthorized copying? Do we lock access, encrypt, etc.?
• How do we address different data definitions, data security zones, data classifications, etc.?
• How do we ensure timely and scheduled updates to our partners? How do we alert each other to changes? How do we ensure partners are not working with expired information?
• Etc.

So, what should enterprise architects do? Get ahead of the conversation, not so much that you get tuned out, but enough that you begin asking the right questions to gauge the enterprise need. Use a multi-pronged communications approach to get the conversation started with business leaders, IT leaders, your own team and other stakeholders. Techniques can include individual discussions, facilitated sessions, and internal social media postings. Once you get a sense for the appetite of the enterprise you may see traction develop. Begin to create hard artifacts for discussion; capabilities analysis first, then principles, then iteratively build increasingly detailed models, specifically business architecture models. Remember that, at any time, you may get too far ahead for anyone to care. You can always park your work and come back to revisit later.

External collaboration is just one of the many questions that enterprise architects might want to think about in the next year. A proactive EA group’s role is to be thinking about high impact, enterprise-wide constructs at least in enough detail to have an appreciation for the issues, the scope and scale of possible approaches. Doing so will inform the organization enough to make the proper decisions when time becomes the critical constraint.

EA Principles Have Little Value

Just recently I learned that a client’s CIO leadership team began a detailed and substantive discussion on EA principles, the implications they carry for their organization, and how they can use them to transform their journey into the future.   I don’t see this as often as I’d like.  While gaining that level of leadership engagement in the creation and use of EA principles has long been a desired outcome, it is still somewhat rare.  In this case, it was a combination of good luck, good timing, and a skilled Chief Architect who was able to keep principles visible and to broker the discussion with leadership.  There is a lesson to be learned here.

With common sense as a significant part of a good set of EA principles, it is easy for a leadership team to write them off as “a statement of the obvious” and not pay much attention.  As enterprise architects, our goal must be to make principles relevant.  The approach is for us to demonstrate how they are used in practice and to show that they are more than a collection of catchy phrases.

For each principle individually, and for the set as a whole, it is important to be able to explain them in real-world terms.  This means choosing principles that guide desired behaviors and explain their rationale and implications in a form that leaders can relate to, with an emphasis on how they affect decision-making at all levels.

Unfortunately, I see many examples of principles that don’t gain traction.   When that happens, EA principles have little value.   When I diagnose the situation I often see that a lot of energy was consumed in creating the perfect written words, with less energy committed to bringing the principles to life.

A few tips:  Always be sure to include rationale and implications, but don’t worry so much about making them perfect, just strive to make them good enough.  Invest the extra energy in bringing them to life in four ways:

1. Ensure that ALL members of the core and extended EA teams understand what the principles really mean and how they are used
2. Be sure to actively and visibly reference the principles in the process of creating future state EA content
3. Refer to the principles and use them as a test in ALL solution architecture and coaching work
4. Carry the principles with you in discussions with leadership at every opportunity

By using the principles every day, their value will eventually be self-evident and leadership teams will recognize them as a helpful tool in their management arsenal.

EA Value Contribution

What value does the EA function provide to the enterprise?  That question consistently ranks in the top ten list of most frequently asked EA questions.  The question, unfortunately, doesn’t lend itself to a simple answer.  It is more often a matter of value being in ”the eye of the beholder”.   In other words, the answer to the question depends on who is asking and what answer they expect to hear based on their personal and professional interpretation of the word “value”.

A systematic, multi-part approach to addressing the value question can lend clarity.  By classifying the various ways that EA groups contribute value, and identifying the stakeholder communities and how they align themselves with those classifications,  each organization can address the value question in terms that are meaningful to their particular stakeholder mix.  In our experience every organization always has multiple value expectations. 

The weighting among various value contributors differentiates one organization from the next.  The weightings will change as the EA function grows and evolves.  To begin to answer the value question, lets define three possible value contribution classes.  These are focused not on what an EA function is, but on what it does for the enterprise:

Project Support:  In some organizations, value is defined exclusively by an individual’s direct contribution to the completion of project-oriented tasks.  While one can argue as to what proportion of individual EA team member’s time is directly or indirectly linked to project tasks, and it will vary by role, skill set and EA maturity, in the aggregate every EA team interested in long-term survival must make their contribution to project completion visible.  After all, it is the rare organization that doesn’t perceive “getting things done” as the highest value component.  As EA teams evolve, contribution to project success will become less hands-on, design-oriented and become more “guidance” oriented as the EA team uses its collective insight into the future state and roadmaps to inform project activities.  In these cases, getting things done “right”, in consideration of both project and enterprise requirements, becomes the operative value contribution.

Strategic Direction: The “raison d’être” of an EA group is to understand the strategic direction of the organization and capture it into a future state representation that reflects the eventual achievement of that direction.  For leaders that believe in EA, their expectation is that the EA organization will invest resources in creation of go-forward standards, patterns, platforms, models and other representations.  After all, an EA team cannot effectively and efficiently perform their “support projects” value contribution if they don’t have a basis to use in providing guidance.  Therefore, creating useable and prescriptive future state guidance, and communicating those directions to the project and asset communities, is a key value contribution that must be included in the mix.

Portfolio Transformation:  It is a rare organization, indeed, that doesn’t suffer from the accumulation of past incremental additions to its asset portfolios (technology, solutions, information, etc.).  Each addition was, at the time, fully justified and sensible in the context of the problem they were trying to solve.  Only upon retrospective analysis does an organization discover the burden those portfolios place upon them in the form of cost, resources, or inflexibility.  Given the future state holistic perspective defined by an EA function, a significant value contribution of EA is to help guide portfolio transformations to shed excess or duplicate components and bring them into alignment with the go-forward wishes of the organization.

By analyzing how the EA function can contribute in each of these categories, and by thoroughly understanding the expectations of stakeholder communities in each, the EA team can strike a balance that will satisfy itself that it is doing the right things, and demonstrate it to leadership as well.

George Paras speaks on “Enterprise Alignment through Enterprise Architecture and Governance”

I am pleased to have been invited to join Ronald Ross, Roger Burlton and many other noted speakers to present at this year’s Business Rules Forum at the Bellagio Hotel in Las Vegas.  I will be presenting on Monday, November 2 during the all-day Business Alignment Symposium and also participating in a panel discussion with the rest of the Symposium faculty at the end of the day.

Use Special Code 9SPGP when you REGISTER to receive a 10% discount!

Title: “Enterprise Alignment through Enterprise Architecture and Governance” 

Achieving ambitious, large scale enterprise transformation demands unique competencies and perspectives, different from those required for day-to-day project execution and operations.  It requires an enterprise view of alignment, bridging big-picture strategy consistently into hundreds of smaller scale implementation and operational decisions.    Enterprise Architecture (EA) and effective Governance are two of those critical competencies.  This session will explore the techniques and approaches that leading organizations use to institutionalize these core management disciplines, reaching beyond the IT department to create a true partnership with business leadership. 

• How to sort out competing Business, IT and EA priorities
• Perspectives: Strategic vs. Tactical, Enterprise vs. Project, Process vs. Content
• The Enterprise View – Capabilities, Portfolios and Roadmaps
• Alignment deliverables for the executive and models for EA consumer
• The human challenge – Culture, People, Persuasion, Roles, Responsibilities

Is it Enterprise Architecture or IT Architecture?

In many of the online EA forums I follow, too numerous to mention all by name, I am seeing an increasing amount of participants questioning whether topics are related to EA or not.   Generally these topics are about lower-level, technology decisions that while within the purview of the overall EA, are really infrastructure/operations level decisions.  Similarly,  many EA events (conferences, webinars, podcasts) have participants who are increasingly asking “Is this still really what Enterprise Architecture is all about?”

This all revolves around a theme that I have been writing and talking about lately – the evolution of EA to be more than an IT-centric discipline.  Now on the surface, this may seem like an academic discussion.  Pragmatically, EA is still an IT organization’s responsibility within the vast majority of organizations worldwide.  While there is no dispute that EA started out as an IT-centric approach, most definitions describe EA to be more of a business-strategy driven approach.  Also, with the inclusion of Business Architecture as one of the domains of EA, practitioners are beginning to need to enter into the forbidden zone — the board room.

If EA is really going to become a method for “architecting the enterprise” rather than using business strategy as a driver for application, infrastructure and data future states, what is needed?   I think one precursor is acknowledged success of the EA contribution within IT.  This requires not only the full support of the CIO, but also the devlopment and collection of metics to support the claims of success of EA.  Secondly, there needs to be a business transformation effort to which the EA method is applied.  I have seen examples of EA being practiced with the business in full partnership (although still primarily applied to decisions within the realm of IT) when there is a major business transformation underway – such as major mergers/acquisitions, changing the business model, or significant modernization.  If an EA team can demonstrate visually and financially that their approach can help senior executives think through not only what their business strategies should be, but also the steps to take to execute those strategies, then EA can begin to fulfill its long-held promise as a business transformation enabler.

The question that I will leave you all with is this:  Can EA be successfully evolved to become a tool of business strategic planners, senior executives and boards of directors if we continue to call it Enterprise Architecture?

This may sound like a trite question, but for most of us that have been practicing Enterprise Architecture for many years, we realize that semantics count.  I believe that in most organizations, the connotations associated with EA are so strongly IT-centric, that it will hinder the ability to transfer the method within the business community. 

What else could we call it?  More on that later.

New EA Book, “Coherency Management”, is Now Available

“Coherency Management – Architecting the Enterprise for Alignment, Agility and Assurance” is a new EA book from co-editors Gary Doucet, John Goetz, Palla Saha and Scott Bernard.    It includes a chapter, contributed by Larry DeBoever, George Paras and Tim Westbrock at EAdirections, entitled “A Pragmatic Approach to Enlisting the Support of CEOs for Enterprise Architecture”.  This chapter covers everything from assessing a leadership team’s attitides and perspectives, to executive messaging, alignment approaches. and specific recommendations on how to engage the CEO and other executive leaders.

With submissions from over 30 authors and co-authors, the book reinforces the idea that EA is being practiced in an ever-increasing variety of circumstances – from the tactical to the strategic, from the technical to the political, and with governance that ranges from sell to tell.  One key message is that  EA must be viewed as an Enterprise Design and Management approach, adopted to building better enterprises, rather than a IT Design and Management approach limited to building better systems.

It is available directly from the publisher, AuthorHouse, or from your favorite bookseller.

 

A new EA book containing a contribution by EAdirections

Podcast available for “Architecture’s Scope Extends Beyond the Enterprise”

As I mentioned in my last post, I was part of a panel discussion at last month’s TOGAF event in Toronto. The podcast is now available at Interarbor Solutions, while the transcript can be found at BriefingsDirect. I would like to thank Dana Gardner of Interarbor Solutions for moderating and producing the discussion panel and podcast. And thanks as well to my fellow panel members, John Gotze and Sandy Kemsley.

George Paras – SITPforum in Minneapolis

I will be visiting Minneapolis on August 19 as the guest speaker at the SITPforum.  This is an interactive, executive round-table session beginning with refreshments at 4 PM.  I’ll be leading a discussion on “Aligning Business and IT” with a focus on IT Strategic Planning, EA and Portfolio Management with side discussions on any aspect of those topics of interest to the group.  At previous sessions in Atlanta and New York I touched on Governance, Organizational Models, Business and Information Architecture, Capabilities Analysis, and how to be an effective IT Leader.

If you can’t attend but know someone in the area, please forward this announcement to them. 

Please send an email directly to me at gparas@EAdirections.com if you’d like to attend.  I look forward to seeing you there.

Survey: Help Us Plan New EAdirections Events

In response to several inquiries, we have created a survey to the larger community to understand your needs for high-quality, practical and pragmatic education including conferences, workshops, webinars, roundtables, etc.  Please take a few minutes to complete this short survey. 

DRAWING – At the end of the survey you will be asked if you would optionally like to enter a drawing for a complimentary one hour Mentoring Teleconference to discuss your IT Leadership, EA, Portfolio Management, Governance, IT Strategy, Alignment, Cost Containment or Transformational Initiatives.