Thursday, March 17, 2011

Enterprise architecture’s quest for its proper identity

This guest post comes courtesy of Len Fehskens, Vice President of Skills and Capabilities at The Open Group.

By Len Fehskens

It is my impression, from what I read and hear in many enterprise and business architecture blogs and forums, that the enterprise architecture (EA) community comprises multiple factions, and which faction you are part of depends on how you answer two questions. These are fundamental questions that I suspect many in the EA community (present company excepted, of course) have not asked themselves explicitly, or, if they have, considered why they would answer them one way or the other.

I believe the answers to these questions color the way we talk and think about enterprise architecture, and until the EA community as a whole comes to a consensus regarding their answers, we risk talking past one another, using the same words but meaning significantly different things. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]

The two questions are:
  • Is enterprise architecture primarily about IT or is it about the entire enterprise?

  • Is enterprise architecture a “hard” discipline or a “soft” discipline?
My answers:

Enterprise architecture ought to be about the entire enterprise, because that’s what the name implies. If it’s really about IT, it ought to be called enterprise IT architecture. Whether or not you believe it’s possible or desirable to apply architectural thinking to the entire enterprise doesn’t change the fact that we ought to name things honestly. And when we name architectures, it seems reasonable to me to expect that if an architecture is implemented primarily in the [x] domain, it ought to be called an [x] architecture. Adding two more syllables (IT) to the seven (en-ter-prise ar-chi-tec-ture), or inserting two characters (IT) in the acronym (EA), isn’t an unbearable burden. Say it – “enterprise IT architecture.” Spell it – “EITA.”

Rarely has the cost of honesty been so modest. If you mean the architecture of an enterprise’s IT assets and capabilities, say EITA. Don’t say EA unless you really mean the architecture of the entire enterprise, not just its IT assets. Even if you consider the needs of the enterprise, or the structure of the enterprise’s processes, if the implementation of the architecture you’re developing will be mostly in the IT domain, it’s EITA, not EA. Even if you believe that architectural thinking can be meaningfully applied only to the IT function of an enterprise, it’s still EITA, not EA.

Soft discipline

My answer to the second question is that I believe enterprise architecture, as scoped above, is a
“soft” discipline. I think talking about “manufacturing” or “engineering” enterprises is just silly; it’s another example of the kind of aggrandizement that misnaming enterprise IT architecture represents.

Even calling an enterprise a “system” is risky. We use the word system in two senses. One is a very broadly inclusive idea, often expressed as “everything is a system,” in that many things can be viewed as assemblies or aggregates of smaller components. This concept of system is useful because it encourages us to take a holistic, rather than reductionist, perspective, acknowledging that the relationships between the pieces are as important as the individual pieces themselves. The other sense of “system” is the one engineers use – a system is an artifact that has been methodically designed and built from interconnected components. Calling something a system in the first sense doesn’t make it a system in the second sense; it doesn’t make its behavior and performance analytically tractable or deterministic.

It is simply not possible to specify an enterprise as completely, and to the same level of detail, as it is to specify a building or a locomotive or an airplane. And, for the purpose of enterprise architecture, i.e., to ensure that an enterprise’s assets and capabilities are aligned with its vision, mission and strategy, it isn’t necessary to do so, even if we could.

It may be possible to do so for EITA, and maybe that’s where the idea that the same can be said of the enterprise as a whole comes from.

Calling something a system in the first sense doesn’t make it a system in the second sense; it doesn’t make its behavior and performance analytically tractable or deterministic.



If the enterprise as a whole is a system, it’s a people-intensive system, and as such one might as well talk about manufacturing or engineering people.

After all, why do we call them “enterprises”? Consider the first definition of the noun “enterprise” in the Oxford English Dictionary: “A design of which the execution is attempted; a piece of work taken in hand, an undertaking; chiefly, and now exclusively, a bold, arduous or momentous undertaking.” Clearly implicit in this definition is that this is something undertaken by people. There’s a nod to this reality when we refer to an enterprise as a “sociotechnical system”, but the “socio” too often gets short shrift while the “technical” gets the bulk of the attention.

Yes, people play a role in other “systems” – they live and work in buildings, they drive locomotives and pilot airplanes. But people don’t just interact with an enterprise; in a fundamental sense, they are the enterprise. And unlike buildings and locomotives and airplanes, enterprises are continually adapting themselves, in the homeostatic sense of maintaining their integrity and identity in the face of internal and external change, and in the sense of deliberately repurposing themselves in response to such change.

How would you answer these questions, and why would you answer them that way? Our answers strongly influence what we believe is within the purview of enterprise architecture, how we address that scope, and what we imagine we can accomplish by doing so.

This guest post comes courtesy of Len Fehskens, Vice President of Skills and Capabilities at The Open Group.

You may also be interested in:

Wednesday, March 16, 2011

Mobile enablement presents challenges, opportunities as enterprises retool apps for the future now

This guest post comes courtesy of Stefan Andreasen, Founder/CTO, Kapow Software.

By Stefan Andreasen

Mobile adoption rates are on the rise and if market reports are any indication, growth rates aren’t slowing down anytime soon. Consumers and employees alike are the driving forces behind mobile adoption spurred by the evolution in mobile device capabilities along with the speed of mobile networks.

A recent Morgan Stanley research study predicts that sales of smartphones will overtake PC sales (including both desktops and notebooks) in the next two years, supporting the demands of our always-connected society. [Disclosure: Kapow Software is a sponsor of BriefingsDirect podcasts.]

The ubiquity of smartphones and more than 300,000 mobile apps available on Apple’s App Store, coupled with the ease and convenience of mobile computing is putting pressure on IT to mobile enable B2C and B2E applications to facilitate organizational efficiency and keep up with consumer and employee demand for mobile access to applications and content.

When it comes to enabling mobile access to mission-critical enterprise apps, companies have made far less progress.



It’s no surprise that millions of employees around the world are bringing their smartphones and mobile devices to work, resetting workplace expectations to have always-on access to the instantly available business apps that they’ve grown accustomed to from their personal lives.

According to a survey conducted by the Yankee Group, 90 percent of organizations surveyed have already enabled smartphone access to corporate email and PIM. Yet when it comes to enabling mobile access to mission-critical enterprise apps, companies have made far less progress, with only 30 percent of those surveyed providing smartphone access to customer relationship management (CRM), 20 percent to enterprise resource planning (ERP), and 18 percent to sales force automation (SFA).

CIOs scrambling

IT leaders and industry analysts are noticing CIOs scrambling to mobile-enable legacy applications to make them available on smartphones, tablets, and even GPS/navigation devices. And, IT departments are feeling the growing pressure to get this done in a matter of months -- to not only stay ahead of the competition, but in many cases, just to keep up.

One of the main challenges companies need to overcome when enabling mobile device access to existing data or legacy applications is the lack of “mobile ready” web service application programming interfaces (APIs) for existing applications.

Adding a service-level interface to a legacy application is a complex development project that typically involves a full or extensive rewrite of the existing legacy application. A common problem is that throughout the years an application has been written and modified by multiple developers, which are likely to have left the company, along with their institutional knowledge about the application. This situation had led many companies to basically re-write the application, which can take several years of coding and insurmountable resources and budget.

This situation had led many companies to basically re-write the application, which can take several years of coding and insurmountable resources and budget



It’s essential that organizations evaluate these important factors when embarking on a mobile enablement project:
  • Do the applications you want to mobile-enable have documented APIs?
  • What components and features of your business application do you want to mobile enable?
  • How are you taking into account form factor?
  • How will you deal with business logic and processes too complicated to be executed on a mobile device with a limited keyboard, where air time needs to be controlled, and server round trips need to be minimized?
  • How will you deal with service interruptions requiring the ability to queue processes for later execution on the back end?
  • Will you be combining data from multiple apps into one mobile application?
  • What mobile platforms do you need to support?
  • To what extent will you want to modify or extend your mobile application in the near future?
The best way to facilitate mobile enablement projects is with focused, goal oriented, up-front planning that doesn’t underestimate the complexity of the process, especially when dealing with traditional data integration techniques.

What many companies aren’t aware of is that there is an alternative approach to developing custom-built, native apps that doesn’t require dependency on pre-existing APIs.

Known as “browser-based data integration,” this emerging approach makes existing business applications and data “mobile ready” by allowing organizations to wrap their existing web application without changing the systems that are already there.

By creating a new web service interface “wrapper” without re-writing any of the existing code, mobile access to enterprise B2C and B2E applications can be possible in days or weeks, not months or years.

It’s no surprise that mobile initiatives are now a top priority for every enterprise. The challenge is to approach these projects as swiftly and efficiently as possible to stay relevant and productive. By combining the proper up-front planning process with browser-based mobile enablement technologies, companies can quickly provide their mobile users with the data and apps they so desperately want and need.

This guest post comes courtesy of Stefan Andreasen, Founder/CTO, Kapow Software.

You may also be interested in: