Mobility and Social Networking: Do You Have a Need for a Strategy?

Two of the biggest trends that many companies are addressing right now are mobility and Social Networking.  Maybe second only to cloud computing in hype right now, these two areas  represent significant opportunities for many companies.  However, one thing that I have noticed is that sometimes the trends with a lot of hype get a lot of attention when it maybe isn’t necessary in a particular instance.

Mobility is not just about providing mobile phones and other mobile devices to all or some of the workforce, but also understanding the security, information and process impact of having a mobile workforce.  Likewise, social networking is not just about marketing products through another channel or managing relationships, but also understanding the culture and demographics of your customers/consumers, suppliers, employees and partners.  So there is some significant thought that needs to be put into leveraging either of these trends for your enterprise.  The question to answer first is whether your business is one that can leverage them given the nature of the way your organization COULD work, given the right tools and applications.  In order to answer this question, which is not a technology question,  you must develop an understanding of business process and information flows in your organization’s operations.  Too often, though, we see the analysis in this area focus on one or both of two aspects:  1) the technology (hardware and software and network) and 2) current mobile workers and executives and social networking users.   The full potential here can only be exploited by understanding the impact of mobility or social networking on the operations of your company (how you design, produce, sell, deliver, and market your products and services) and the relationships that your company maintains.

While it is likely that either mobility or social networking can have a positive impact on one or more aspects of your enterprise, you must be prepared to look beyond the technology and current state of operations to leverage them.  Sounds like a job for EA.

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

A couple of months ago, we published part 1 of Top 10 Things an EA Should Be Thinking About.  Now we add a few more, with considerations for the New Year.  To get started, I will repeat what we said in part 1 as the means of introduction…

…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.

6.  With increasingly creative business partnerships forming in the marketplace, how can we effectively share information and collaborate with partners while protecting business confidentiality and adhering to regulatory concerns.  Are there general rules we should develop?  This is a dilemma of the new century.  The types of partnerships forming between suppliers and buyers, between former and even current competitors, between public entities and constituents, and between producers and consumers are primarily being created to share/consume information rather than products and services.  Another factor to consider is the element of trust, as the use of information outside the enterprise boundaries may be impossible to monitor and control. 

7.  As increasing amounts of information about customers, markets, transactions, sensor status, etc. flow into our company, are we able to effectively analyze 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?   The amount and size of data are increasing at a tremendous rate for most companies.  While the hardware to move, secure and store this data is an issue in and of itself, the more pressing issue is how to utilize the information to your enterprise’s benefit.  The focus needs to be on the information consumers.  Who can use the information to support their work activities and/or decision making processes?

8.  How does our enterprise “measure” or represent value?  What are the most important factors of success to our executive leaders?  Are they being measured?  How can EA facilitate the achievement of those success factors?  We are often asked how to measure the value of EA.  Short answer: Measuring EA’s value is dependent on the measurement of value in other activities influenced by EA, and most organizations are not mature enough in their general performance management capabilities to support the ability to measure the value of EA.  So the workaround is to figure out how EA can enable those factors that are most important to executives and show the indirect linkage that EA has to contributing value.  But it all starts with understanding what your executives value.

9.  With the current aggressive pace of marketplace and technology change, have we made the right decisions to be nimble enough to respond ahead of our competitors?  How important is agility to the business and are we prepared to be innovative?  How can I make the enterprise understand the need for adaptability?  This is not a NEW question, by the way, as those of you who have followed us for the last 15 years know.  But as time goes by and these paces continue to accelerate, these questions become even more important…as we have been saying for the last 15 years.

10. Where are the decision-making bodies and processes disconnected in our enterprise?  And once you identify them, how can you create a visualization of these broken chains?  EA is part of the planning and decision making ecosystem of your enterprise.  Influencing decisions and plans for investments and implementations is the outcome of a well functioning EA program.  In order to do this effectively, you need to identify where to influence these decisions and convince executive leadership that EA has a place in the process.

We would love to hear what are readers are thinking about in 2011.  Please share with your comments.

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.

Market Driven Enterprise Architecture Survey

Market Orientation is a business planning discipline that stresses an understanding of market conditions and their impact on your enterprise as the major driver for operational and strategic plans. Obviously, this should then also be a major driver for EA planning. Regardless of whether you formally adopt Market Orientation in your enterprise, you will find the survey interesting, and the author (a colleague of ours, Hjalte Hojsgaard) would much appreciate your time and consideration.  It is a 10-15 minute effort.

You can access the survey by clicking here.

Thanks for your consideration.

Transformational View of EA

OK, so you think you are practicing Enterprise Architecture, right? As I have pointed out before, the key is the answer to the question, “Are you architecting the enterprise, or are you architecting IT?”

As I dare say, most of you (if not all) would answer honestly that you are architecting the IT environment (apps, data and infrastructure), albeit with a significant alignment with the business of your enterprise. In any case, as I have been having this conversation with audiences, practitioners and clients over the last couple years (or even longer as a client of mine pointed out yesterday – Thanks, Marc!), I have been suggesting that true EA requires business-owned Enterprise Business Architecture (EBA) and Enterprise Information Architecture (EIA).

The implication of this suggestion is that the EBA thought of in the traditional sense is not within the domain of IT; but rather owned, driven and primarily developed and maintained by a group of business professionals within the enterprise. Further, there is also a separation of EIA and Enterprise Data Architecture, with the former under business direction and the latter under IT direction, joining EA efforts for application and technology. Figure 1 depicts the relationships described above.

There is a role for IT EA professionals to play. As the figure suggests, a relationship exists between the business domain and IT domain. Initially, the IT architects must translate the impact of the business and information domain upon the architectures within the IT domain. This is done primarily through modeling and capabilities analysis, a topic for another time. IT professionals have the modeling experience, plus a vested interest in the outcome of the business and information architecture efforts, to be valuable members of the team working on the business domain architectures.

Recently, I have been working with an organization going through a significant transformation and they decided to do exactly what I have been suggesting. A group of business representatives including IT representation, lead by a representative of the executive leadership team, has taken ownership of business and information architecture to define how the business will transform. It will then become the IT Chief Architects responsibility to lay that business blueprint on the IT landscape to translate the changes necessary within IT to support the business transformation.

Let’s hope this is the beginning of a trend.

Social Networking – What’s good for them is good for EA

Enterprise architects have historically struggled with the process of publishing content to the stakeholders in their organization.  Conventional advice has been to create an intranet site or other document repository primarily serving static documents such as strategy papers, standards lists, domain architecture documents, models, etc.   That approach has its weaknesses, not the least of which is that the content and access methods aren’t particularly engaging to the larger community of casual stakeholders including members of the extended EA community of subject matter experts and contributors, and the more formal members including senior managers and leaders in both IT and the business.

Many organizations have begun to deploy blogs, wikis and other related social networking technologies in response to demand from various user communities for easy to use tools that support collaboration and information sharing.   In fact, many EA practitioners are well down the road choosing social networking technologies and helping the business develop usage guidelines.  

Surprisingly, EA practitioners as a whole have been reluctant to embrace the use of social networking for their own purposes, namely to share their thoughts and ideas with others in the enterprise, and to welcome commentary and perspectives from interested parties outside their own groups.  The key is to become comfortable sharing trends, ideas about the impact of those trends and thoughts on future EA changes, even before fully formed.   Post often and openly, resist the urge to assign rigorous categories, and tag and link freely.

The technology, and the behavioral changes that can result once the team becomes comfortable with it, can help improve the perception of the role of the EA group by the rest of the organization.  It can further recruit additional participants, effectively multiplying the reach of constrained EA resources.

Webcast on Business Architecture

We have made our position pretty clear on this topic, but  just to make sure everyone caught it - We think that 2010 marks the year that Enterprise Business Architecture has finally become a legitimate concern for a singnificant number of organizations, probably more than a quarter of organizations practicing EA. 

To further clarify some of our thoughts, George and I sat down and recorded this webinar. 

EAdirections On Business Architecture

View more videos from Tim Westbrock.

Let us know what you think.

CIO’s and EA – Leadership Challenges in IT

We ask a lot of our CIOs.  Just follow the myriad magazine articles and research pieces targeting CIOs to read of the breadth and depth of expectations heaped upon a single role.   The industry experts who define what CIOs ”should be” suggest that they must be technology visionaries and innovators, business transformation change agents, vendor relationship negotiators, savvy business managers and human capital performance motivators, cost-cutters, quality experts, portfolio managers, talent scouts, have operations and service management knowledge, be technology, process and solutions aware, passionate leaders and experts on the company’s industry, etc.  The list goes on.  Actually, I agree with all of these traits and more – they are all required.   It’s a tough job and can’t easily be characterized into a simple role description.    

As a case in point, I have been following Bob Evans’ column in Information Week of late.  I enjoy his perspectives.  His most recent column, “Do CIOs Still Matter“ , struck a chord in me.  He listed ten ideas to get started redefining a CIOs roles and boundaries.  Many of his points spoke to things that we have been coaching our Enterprise Architecture clients on for years.  In particular, he commented that today’s CIOs “spend too much time on the tech side of IT and should instead be more involved in technology-enabled business growth and customer intimacy”.  Other points included “lead the charge in seeing the future”, “drive transformation” and my favorite, “be a business-model buster”.

So, what is the CIO to do?  How can a CIO be tactical and strategic, responsive yet not reactionary, thoughtful and systematic yet not slow and obstructionist, operational and also transformational, cost-sensitive while investment and growth oriented?  The simple answer is that in all but the most extraordinary individuals, it isn’t possible, or it is at least unlikely that all of the required personality traits and knowledge can co-exist.  The best approach to being broad and deep enough is to surround him/herself with a strong team, with each member focused on different aspects of the role.   The best CIOs are already doing this, realizing that the CIO role isn’t intended to be a single super-human (though many white papers seem to suggest that and some CIOs try to become one) but is instead an aggregation of the skills and talents of a group. Traditionally, that group is called the “Office of the CIO”.

Many CIO’s already recognize that they can’t personally be everything to everyone and that they must have a great staff.  Most CIOs put a director in charge of the data center with a focus on operational efficiency and meeting service levels.  One or more directors are usually focused on solutions development and delivery.  The better organizations have a PMO in place to shepherd the project portfolio, though most PMO’s are low maturity engaging in mainly project tracking and reporting.  More on that in a future article.  What is missing in most CIO Offices is a person responsible for the big picture future state business context, the holistic cross enterprise perspective, the long view of the health and utility of the asset portfolio, and to address larger concerns like complexity management, portfolio optimization, integration, and the integrity of the information, technology and business architecture assets.  These activities and perspectives are embodied in the role Tim and I have prescribed to the “enterprise” architect since we began in this discipline in the 1990′s.    

While empowering a diverse IT leadership team is necessary, successful CIOs also understand that the buck stops with them, so they need to be able to make sound decisions when the rest of their staff doesn’t.  One powerful way to be sure the staff can address all the perspectives above, including the longer term, holistic enterprise view, is to elevate the Chief Architect to be a full member of the Office of the CIO.  If you have an EA function, but it is doing only the subset of enterprise architecture that we describe as “IT” architecture ( which usually means they reside several levels down in your organization)  then augment their skills and personnel and have them engage in the strategic and business-oriented discussions described above.  You will find them to be a valuable addition to your core team.

Stay tuned, we will be writing a lot more on the placement of EA in the Office of the CIO, the complimentary roles that exist in the Office, the dynamics, politics and culture of the team at that level, and the processes, perspectives, and leadership skills required for that team to support the breadth and depth of activities expected of the modern CIO.

My Take on the Q&A from the The Open Group Seattle Event …

I recently attended The Open Group Architecture Practitioner’s conference in Seattle.  During the event, I was given the opportunity to present a Keynote on the Language of Business Architecture, which I thoroughly enjoyed.  A couple of my peers, Mike Rollings of Burton and Henry Peyret of Forrester, were present and gave interesting presentations, as well as participated in a panel discussion, with Business Architecture themes.  There were several questions posed during the panel and Q&A sessions following their presentations upon which, surprisingly, I also had an opinion.  With apologies to Mike and Henry, I thought I would share some of them with our readers.   And George has an opinion or two, as well.

Q1:  If Enterprise Architecture as practiced by most is really IT Architecture and Enterprise Architecture is not a term that will be embraced outside the IT organization, what should we call it?

Tim’s Answer:  Although it is not as catchy, my first thought was Enterprise Planning & Optimization.  Until something sexier or more appealing comes along, this is my suggestion. 

George’s Answer: I can live with that and have never found anything better.  Several years ago, at successive Enterprise Architectures Conferences (EACs) I ran working group sessions to “rename” EA.  Each time, the group concluded that ”even with all the undesirable connotations of the name ‘EA’, we can’t come up with a better name”. 

Q2:  Have you ever seen EA report outside of IT?

Tim’s Answer:  To this point, I have not worked with a company that has the EA function reporting outside of EA permanently; however, I have worked with companies where the head of EA has had occasional assignments working for a corporate executive (not line-of-business) on strategic initiatives. 

George’s Answer: I have seen a few forward-looking organizations exhibit EA-like behaviors with notions like future state, enterprise principles, enterprise operating models (a la “EA as Strategy” – Ross, Weill, Robertson) as context, etc., usually within the enterprise strategic planning function.  They never call it EA, though.

Q3:  Do you see many EA groups with defined qualitative metrics?  What are they?

Tim’s Answer:  Most EA groups need to have some kind of metrics or KPIs in place, and as most of the benefits of EA are indirectly realized through the efforts of others (project teams, operations, procurement, etc.), they tend to be qualitative.  I have seen clients measure reductions in complexity and asset portfolio mix that have both qualitative and quantitative elements to them.  Perhaps the most common qualitative metric I see is a periodic assessment of EA maturity/effectiveness.  Organizations compare the ratings in different categories from one year to the next to see where they are improving and where they are lagging.

George’s Answer: I agree with Tim and would add that, occasionally, I see many organizations implement specific quantitative measurements because their HR systems require them to have something designed to evaluate individual and/or group performance.   These tend to be behavioral measures, not value measures.  Examples include completion of specific EA deliverables, or reducing the number of EA exceptions requested by projects.  The latter is achieved by creating appropriate reuseable patterns that have high utility across the enterprise, solving specific implementation scenarios in a repeatable way, through education and project coaching, etc.  The leadership team must believe that these behaviors will eventually drive desired outcomes in the company if the architect is to have any chance of representing these as legitimate metrics.  

Q4: In large organizations, line-of-business (LOB) architectures abound.  Is this an inhibitor or opportunity?

Tim’s Answer:  I think that it can be both.  If you do not create a unified, but federated, EA practice across the organization, then you run the risk that the LOB architectures are inconsistent, increasing cost and complexity overall.  Also, the LOB EA groups will tend to be more customer-focused, giving the LOB what they want, which makes it more difficult for Enterprise-level architecture decisions that are optimal company-wide, to be embraced at the LOB level.  This federated approach is what we see at most large complex organizations, so it must be turned into an opportunity to be successful.  Without leveraging the extended architecture community, the EA will probably be largely unsuccessful in large organizations.

George’s Answer: It could be both, but being a cup half-full person, I usually see it as an opportunity.  If even a small part of a large organization can do EA successfully, that’s good for them.  With luck, it will spread and grow to others.  If there are multiple LOB EA’ish functions, perhaps they will be able to identify opportunities for commonality and leverage, but only if that really makes sense for that particular company.  If critical mass or commonality never materializes at the big-”E” enterprise level then at least part of the company has embraced EA concepts.

Q5:  How do you define a business capability?

Tim’s Answer:  To me, business capabilities are the next layer of abstraction below business strategies and objectives,   defined as the capabilities that the business operations must deliver to achieve those strategies and objectives.  Since capabilities are usually defined at a higher level than requirements, there is more opportunity to find capabilities that cross organizational and functional boundaries.  This approach helps identify the areas to which we can architect, rather than getting right to the solution. 

George’s Answer: This is a tough one because everyone has their own interpretation.  The simplest one I have seen defines a capability as “the ability for an organization to perform a particular piece of work”.   I like it BECAUSE of its simplicity.  Of course, then one must be able to define “work”.   One example capability might be, in a product company, packaging and communicating product features to potential customers.  That capability manifests in the marketing function.

Q6:  Do you think the long-term future of EA is to merge or disappear?

Tim’s answer:  I think for the vast majority, the answer is neither.  Ultimately, EA is all about leadership – providing it and being recognized by it.  It seems to me that the leadership of most organizations is interested in surviving, keeping the status quo, and being tremendously risk averse.  In those kinds of circumstances, I see EA following the enterprise leadership and basically staying the same.  Those organizations that truly embrace EA’s transformational capabilities and allow it to reach its potential may end up creating a hybrid version of EA – one part that continues the traditional IT architecture leadership under the CIO called EA, and one part that merges into the executive offices to provide leadership in planning and strategy, called something other that EA, perhaps Business Architecture (but I kind of doubt it).  In these cases, there will be a strong relationship and integration between EA and BA. 

George’s answer: I have long maintained and continue to be of the opinion that a well-run EA program “melds into” and becomes part of the management and decision-making fabric of the enterprise.  It isn’t EA itself that we ultimately care about – it is just the name we are stuck with to represent a future-oriented, holistic, business driven, enterprise-wide context that informs decision-making.   What we really care about is the installation of those EA-like concepts, behaviors and an enterprise context into how the enterprise works – whether it is called EA or not.   By the way, I think we are a long way from this happening for anything more than a relatively small fraction of organizations.

Let us know what you think.