Lack of Enterprise View a Hindrance? Good Solution Architecture is Not Enough

We are consistently being exposed to ENTERPRISE architecture teams without an enterprise perspective in the deliverables and activities in which they are engaged.  Sometimes this is due to a cyclical shift in the priorities between defining enterprise architecture and applying enterprise architecture via solution architecture.  This is a normal, healthy shift that we see happening in maturing EA programs.  However, the occurrence I would like to touch on is when there has NEVER been an enterprise perspective, yet there is an enormous priority placed on solution architecture resources and activities.

I have to ask myself if these enterprise architecture teams understand what they are missing.  The enterprise perspective is embodied in activities and deliverables that are not only enterprise-wide in scope and objectives, but also forward-looking, strategic, holistic and business-driven.  Relative to solution architecture (SA), the goal of EA is to provide this enterprise perspective so that SA’s can guide the tactical, technical, siloed project-oriented activities to fit with the long term business and technical direction of the enterprise.  Without the enterprise perspective, the SA’s are only guiding projects to fit within the technical best practices and emerging trends from the perspective of an individual SA or SA group.  Valuable, yes, but not EA.

But there is an even greater impact to an organization of an EA without an enterprise perspective, and that impact is felt by other  planning groups relying on EA to provide that long-term, holistic, business-driven, strategic view.  Budgeting, portfolio management, change management, strategic planning, sourcing, and operations planning all tend to happen with an eye on the short-term and tactical.  Without EA fulfilling its obligation, these plans are likely to be inconsistent, abandoned quickly, lead to waste, and ultimately, diminish confidence in the IT organization, the CIO and the IT management team.

The excuse that many EA groups are using is that there is a focus on the short term because of the economy, resource shortage or lack of business strategy from the enterprise leadership.   This excuse might hold weight for organizations just getting started with EA in the last 2-3 years, but what about the EA teams that have been operating for 5 years or more and NEVER developed the EA perspective.  Simply put, it is usually a lack of leadership and understanding of what is needed to create the enterprise perspective.  We counsel organizations to do the work to create a baseline of the enterprise perspective and use that to help leadership understand what the enterprise perspective is and how they can use it.  Good leaders will make use of it, and understand that now is the time to be looking forward.

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.

EA Tips – Substance OVER Structure

If you read my post on “Style AND Substance” I stated that an EA team shouldn’t spend disproportionate energy on content creation without also paying attention to the many softer, stylistic elements associated with leadership and influence. One without the other and the team will fail. In this “EA Tips” post on “substance vs. structure” I offer that an EA leader should worry only slightly about organization and team structural issues and spend as many cycles as possible jump starting the EA team and getting them to work together to produce meaningful content (strategies, standards, roadmaps, etc.).

Every EA team I work with these days is overloaded. I believe that much of the time spent worrying about structure and organization is time better spent elsewhere. Yes, I know that there are just some HR issues that must be addressed, team members need job descriptions and performance plans, and frankly most people won’t even join a team unless they have a reasonable understanding of their responsibilities and how performance will be recognized.

Beyond that, though, I find that many leaders find themselves slicing and dicing roles too finely and creating a lot of unnecessary work for themselves. In fact, doing so often works against the team and inhibits their ability to be effective. The team becomes just a container for a collection of individual contributors, basically working alone and rarely interacting. The very essence of EA is that everything, in some way or another, depends on everything else. The more you separate coverage areas, the more difficult it is to stitch it all together.

Basically, I am saying to not sweat the organizational issues any more than you must to get a few strong players onto your core team. Don’t be too concerned about segmenting responsibilities discretely among domains. Let individual assignments adapt to the content needs of the enterprise and allow your core group to float among them, learning, growing, and sharing perspectives. Encourage everyone to work together as a team and dynamically rotate individual leadership and deliverable assignments. The team will be better off and the members will be as well, plus less time will be spent deciding who does (and doesn’t) do what and more time will be spent on results.

Location, Location, Location – Where Should an EA Team Report?

At the recent Troux Worldwide Conference in Austin I moderated two panels, one on Top Performing EA Teams and the other on EA Leadership. We had many questions submitted by audience members and were unable to answer them all. In the next few weeks Tim and I will be offering our perspectives on some of the questions the panels didn’t have time for and share thoughts on a few they did. “Where should an EA team report?” was one of the latter.

It seems that many EA teams we talk to ask about reporting structure, either as reinforcement that they are in the right place now, or as justification for reorganization if they are not. If I had to answer, without knowledge of an organization’s specific circumstances, I would say something like “given the latest trends in enterprise architecture towards stronger business architecture, the EA Team should ideally report directly to the CEO or executive committee in some form of a strategy function”. This gives the team the imprimatur of executive authority, strong visibility, and broad reach across business and IT concerns – truly the “enterprise” perspective.

But that answer isn’t realistic in most current organizations. First, we’d have to establish that the team is really doing true “Enterprise” architecture vs. IT architecture. A good discussion on what we mean by this is included in Tim’s blog entry from last year on The Transformational View of EA. Transformational EA specifies business architecture that is owned, driven, developed and maintained by business people as opposed to their IT proxies. It is coordinated in partnership with IT architecture-oriented EA’s focusing on the IT and systems-oriented perspectives. Until that happens it is unlikely that an EA Team will reside at the level of my answer above. If it has happened already, they have probably been moved up to that level or are already well on their way.

The question most EA teams should ask would be “What is the best place for EA to report in MY organization and how do I get there?” The first part of that is a much more straight-forward question to answer. For a Team working on IT architecture the best place to report is directly to the CIO as part of an Office of the CIO, along with the PMO, IT Strategy Group (if not already the EA group), and other CIO functions. This positions the EA team organizationally on par with operations/infrastructure, security/compliance, and development/support.

Many EA teams find themselves deeper in an infrastructure group doing technical architecture or as part of development support organization. Is that bad? Not necessarily. It is the starting place for many EA Teams. It’s only bad if the scope and scale of the team’s reach is constrained by it. I have seen cases where the EA team administratively reports into a supportive infrastructure director (or development director) who recognizes the value of EA, their role, and gives them license to practice something closer to holistic, forward-looking, business-driven EA. After all, good EA teams are not self-contained. They are highly dependent on engaging a virtual community of stakeholders and contributors from across the organization. Where the team reports, provided again that the leader is supportive, is less important than what it does and how it reaches out to influence others.

So, the bottom line answer to the question of where an EA team should report cannot be from a purist perspective but instead should be based on a combination of practical realities along with the vision and aspiration of the team to drive value. Whenever I hear the “where SHOULD we report” question I prefer, instead, to deflect it and work with the team to answer the question “how can they drive maximum value”. If they can’t do it where they are then we determine, realistically, “where COULD they report”, and “what will it take to get there?”

IASA Chicago Chapter Inaugural Event April 7- George Paras Featured Speaker

Thursday evening, April 7, marks the inaugural event for the new IASA Chicago Chapter.  The meeting will be from 6:00pm-7:30pm at Illinois Technology Association (ITA), 200 S. Wacker, 15th Floor, Chicago.  The new chapter provides a networking and educational forum for IT and Enterprise Architects from across the Chicago area.  I will be leading a session on “Changing Architects’ Conversations”, sharing tips and techniques on how architects can create and take advantage of opportunities to engage enterprise leadership in strategic conversations.

In addition to speaking at the event, I am honored to have been asked to serve on the Advisory Board for this new chapter.  Please invite your architecture colleagues to come and join us!

Event and Registration Details

Top-Performing EA Teams – A Panel Discussion

I had the opportunity last week to moderate two panels at the Troux Worldwide Conference. The first panel included EAdirections’ Tim Westbrock along with Mike Walker from Microsoft, Aleks Buterman from SenseAgility and Paul Preiss from IASA. The theme of the panel was a general discussion on characteristics of top-performing EA Teams. To begin the conversation, I asked each panelist to describe what a top-performing EA team meant to them. What I had originally believed to be a softball question that would show the breadth of issues and perspectives on EA turned out to be more controversial than I had expected.

The panel became caught up in the role of EA and the role of IT architects. Unfortunately, the conversations became focused on the differences in the roles instead of how they work together, diving too far into a differentiation of the “primary” roles and skills of each. It revealed some of the confusion around EA and shone a light on many of the issues that practicing enterprise architects must deal with on a daily basis. What I had hoped would be a conversation addressing how the EA function must be multi-purposed, strategic and tactical, business and IT-oriented, and with an eye to both short and long-term value delivery became overly focused on narrower perspectives. We had a few rough spots as we worked our way through the session, but luckily we ended well. We landed at the recognition that while the roles are different they share some common skills and, after all, they should be collectively working to achieve positive results for their organizations. Individuals in both of these roles will inevitably be working closely with each other.

Personally, I believe that the biggest part of being a top-performing EA team is learning to strike the right balance across the perspectives listed above. It isn’t about doing just one thing or having a “primary” concern as much as it is about how well the EA leaders cover the bases, shifting emphasis from strategic, business-oriented concerns, to helping certain initiatives head down the right path, and then back again as dictated by the situation. It is about breadth, and reach, and longevity.

In future posts Tim or I will examine several of the questions asked by the audience, some answered by the panel and others that we didn’t have time to address.

Improving EA Team Performance

With the arrival of the New Year, many EA teams are in the final stages of setting their annual objectives.  This year, we find that many are being asked to perform at a level significantly higher than last year.   They must do so in response to higher expectations placed on them by leaders who believe that EA plays a critical role in moving the enterprise into the future.  

Many annual objectives documents are primarly structured as lists of projects  and deliverables that the team must complete in the next planning period.   While hard deliverables are necessary and expected, every EA leader should also consider adding objectives designed to improve team performance and to address “how” the team is going to accomplish their assignments.   Why?  Because EA success requires predictable and consistent performance by the team as a whole and by its individual members.

One of the most interesting observations from studies of EA team performance is that the typical team profile of a collection of highly skilled and specialized individual contributors isn’t necessarily optimal.  To be successful, teams populated that way must learn to function as a team, supplementing the natural tendency for individuals to work alone.  Enterprise architecture is inherently cross-domain in scope.  Only by working in collaboration across domain specialites will the team be able to quickly address the many dependencies that are part of the modern enterprise.   

We recommend that EA leaders employ the following techniques when striving to improve their overall team performance:   

Develop a common language: Words and concepts are important.  Adopt/adapt a “language of EA” that makes sense for your organization.  A common grounding in EA core concepts can go a long way to unifying a team.  Look to the more widely used and common industry approaches to EA, take a class, or ask us.  We’re happy to make recommendations on practical approaches that will work, and show you how to adapt them to your needs.

Be a Team: Get together frequently, in person and/or virtually.  Eschew “project status reporting” meetings in favor of strategic discussions, cross-domain issues resolution, trend analysis and healthy debate.

Collaborate and Communicate: Actively recruit and engage external parties and bring them into the discussion.  Learn to exploit “social media” style connections to engage with these larger audiences. 

Learn to Lead: EA is a “lead through influence” discipline.  Take a leadership course, but be careful to select one focused on “soft” leadership styles.  It isn’t about traditional personnel management techniques.

With people as the critical element to EA success; it only makes sense to invest in team skills and performance.   Unfortunately, many teams put disproportionate emphasis on templates, frameworks and deliverables.  Make it a practice to visit/revisit the health and productivity of the team.  Don’t wait until next January to start.

Top 10 Things an EA Should Be Thinking About (Part 1)

So it seems like that time of the year again where different analysts, experts and bloggers are coming out with Top 10 trends lists.  While some might view the yearly generic crop of “Top 10” lists as trite, superficial, or simply  repeating things everyone already knows; we thought we would take a stab at a list that would be different than other Top Ten EA trends lists.  We typically see the same technology-oriented trends peppered across these lists, with little or no business context around them.  Quite frankly, it is the business that matters the most, and that is what we would like to see EA’s thinking about… not just now, but all the time.

Our list represents the Top Ten (or so) things that we think true Enterprise Architects should be thinking about.  As always, this represents our thinking that Enterprise Architects should be focused on the whole of the enterprise, business and IT perspectives, long term business strategy and transformation, and the impact that has on the work that needs to be done beyond the here and now.  Not the kinds of things that solution architects, data architects, application architects, infrastructure architects, or security architects should be thinking about – What should ENTERPRISE architects be thinking about?

 Not listed in order of importance – they are all important.  Also, we would like to tell you that a typical IT-centric Enterprise Architect may not be able to answer these questions or think about them as completely as they should – in which case, they need to seek out the appropriate business and/or IT professionals to discuss these topics with from the perspective of their enterprise.

1. Are our business’s customers the type of customers we can reach through social media?  If so, how does that change our marketing and product/service development operations?  Social media gets a lot of attention, and in certain circumstances, can be a valuable and powerful employee relations, marketing, customer service and product delivery tool.  But social media is not for everyone.  EAs need to think about and discuss the impact that these tools can have on employee, partner and customer interactions with people that are knowledgeable in these areas. 
2. As more and more business applications are made available via “the cloud” (which is really another way of saying externally provided over the internet for our purposes), how can that change the way we work?  The “cloud” seems to be everywhere.  I don’t want to see an EA thinking about all of the technical capabilities enabling and roadblocks constraining cloud computing – there are domain architects and engineers and vendors for that.  I want to see them thinking about how the business would change with software, infrastructure and information “virtually” available from any browser, anywhere.  And I want them discussing the financial ramifications of using externally provided services with the finance department and IT finance personnel.
3. How can we more effectively leverage our information assets?  Is there information we have that others would pay for?  Is there information that we don’t have , that we can get from other sources?  As increasing amounts of information about customers, markets, transactions, sensor status, etc. flow into our company, I would like to see EAs having conversations with information consumers and executives about effectively analyzing that information to increase profits and/or value to our constituents?  Can we handle it, manage it, store it, protect it, etc.?  Which work processes must change or be invented to operate in the new environment? We continue to believe that information is one of the most underutilized assets of most enterprises.  This is a prime opportunity for EA to deliver value.
4. How should we guide sourcing strategies? based on cost, commoditization, competitive advantage, etc.?   Is it in our best interest to maintain captive skills or acquire them elsewhere?  As an outcome of thinking about most business and technology related outcomes, EAs should consider the impact that new business operations, channels, technologies, etc. have on the skills and training of the enterprise’s personnel.  This provides insight into alternative sourcing strategies and the time and cost impications of each. 
5. What level of business process standardization and what level of business process integration does our business’s operating model require? More importantly, which business processes should be standardized (allowing for more leverage of the supporting business applications) and which business processes need to be integrated (allowing for more leverage of the shared information assets)?  All too often, I speak with enterprise architects who are having a hard time having a meaningful, high level discussion with business executives about how the business operates and how that relates to what the IT department can offer.  At the same time, I see information technology departments struggling with justifying the integration and data management technologies that the business seems to need.  The discussion about the enterprise’s operating model is one that I find executives understand and find meaningful in the way it relates business operations and IT investment decision making. 

So there is the first half of our Top 10 Things EAs should be thinking about …  We will finish our list in next month’s newsletter (click here for details on one of them).

Let us know your top 10 things to think about.

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.

Enterprise Architects as Change Agents

Last week I read a blog post by Rosabeth Moss Katner talking about Leadership and seven sayings that can guide and comfort those trying to drive change.  It was a good post and I tweeted it along with the comment “good advice for enterprise architects and other change agents”.   Since we began our interest in EA, Tim and I have embraced the slogan that “Enterprise Architects are Change Agents” and have used it as a theme when coaching and teaching. 

Lately, though, it seems that many EA practitioners don’t understand what the concept of “change agent” is all about and/or how to make it real, or are comfortable or constrained to only work on change at the micro (project, product, system, etc.) level vs. the enterprise level.  I wanted to take this opportunity to reinforce the concept that being an effective enterprise architect often means acting as an agent to drive large-scale change into your culture, influencing larger communities of people to engage, interact and make decisions in a non-local, non-micro “enterprise” way. 

The quotes Ms. Katner’s selected for her blog post are from herself and also from various literary and historical figures.  They are spot on and highly relevant to the EA community, specifically as applied to our role as leaders and change agents.  Some examples:

The quote from the Cheshire Cat in Alice in Wonderland that “If you don’t know where you are going, any road will take you there” speaks directly to the main focus of our work. Creating a coherent (and “business first” – see Tim’s accompanying post) future state enterprise architecture becomes the target that all paths must lead to.  Engaging leadership in discussions about the substance and form of that future state is the key to success here – finding the context and the opportunity is the tactic and there are many possible approaches.

The quote from Yogi Berra that “when you come to a fork in the road, take it” implies that we as enterprise architects sometimes must “stir the pot” and experiment, to not be afraid to float ideas before they are fully baked and see where they lead.  The fear of making mistakes is often so intrinsic that it paralyzes many of the EA teams that we have helped over the years.   Today, with internal social networking, many organizations now have vehicles where open, lower-risk exploration and trial-ballooning can occur.

Becoming an EA cultural change agent isn’t for everyone, but many reluctant practitioners have discovered that they are capable of doing it, once they embrace some of the concepts described here, practice them, and become confident in their abilities.