Showing posts with label FEA. Show all posts
Showing posts with label FEA. Show all posts

September 15, 2007

SOA – Does the Emperor Have Clothes?

Architecture and Governance Magazine, Volume 3 Issue 3, reports that one of the Top 10 Challenges in Enterprise Architecture is “Getting Ready for Service-Oriented Architecture (SOA)”.

- Why is SOA proving to be such a challenge?

The article reports that “most architects have not done much of either substance or significance in this area.” Further, “most of what enterprise architects have addressed in this space concerns aligning IT with the business and governance”—and this is something that EA has been doing all along anyway.

- So what has SOA changed?

“What has changed is the promise of abstracting services that can be reused.”

However, some have questioned SOA:

  1. Is SOA “just a revival of modular programming (1970s), event-oriented design (1980s), or interface/component-based design (1990s)”?
  2. Is SOA “just another term for Web Services”?
  3. Is SOA “merely an obvious evolution of currently well-deployed architecture (open interfaces, etc.)”? (Wikipedia)

Others have questioned if SOA and EA are even distinct disciplines?

“So, has SOA in fact evolved into EA? A to question to which the answer is yes and no." The author continues, “essentially there are three evolutionary paths:

  1. EA is absorbed by SOA
  2. SOA is absorbed by EA
  3. EA / SOA merge into a new concept”

Finally, the authors propose #3 merging EA and SOA as follows:

“SOA-A+EA = SOEA”

With the conclusion that “in order to create this holistic view EA and SOA must not be seen as separate disciplines, but to see the two as one will bring changes on such a scale that we are now talking about SOEA Service Oriented Enterprise Architecture.” (Journal of Enterprise Architecture, August 2007, Rasmus Knippel and Bo Skytte)

While the authors apparently seems to think SOA is important (although they call it "increasingly more abstract"), the relationship to EA is changing and unclear—Not sure this idea about SOEA is helpful at this juncture!

- How helpful to SOA development is the guidance from the Federal Enterprise Architecture (FEA), Service Reference Model (SRM), which talks about services and capabilities?

Not very! The SRM is supposed to “provide a high-level view of the services and capabilities that support enterprise and organizational process and applications.” (FEA, SRM). However, the service domains, service types, and capabilities listed in the FEA SRM are quite muddy, at best. Here is an example:

  • The domain of Process Automation is defined as “the set of capabilities that support the automation of process” [hasn’t every 5th grader been taught not to define a term with the same term?]
  • And it continues “and management that assists in effectively managing the business” [well that is a pretty broad definition— can’t all services assist in effectively managing the business?].
  • Then after the definition, you’re expecting some pretty extensive process automation services, but the SRM lists just 2 components:
  1. Tracking and Workflow (which includes capabilities like case management [what’s that doing here?] and conflict resolution [isn’t that a leadership skill set?])
  2. Routing and Scheduling, which includes just Inbound and Outbound Correspondence Management [so where the scheduling piece like calendaring or time management that one normally associates with scheduling and how does the routing as in Routing and Scheduling reflect the routing inherent in Tracking and Workflow category above—seems like some category overlap]

I’ll let you look at the SRM yourself to see evaluate the clarity of the other categories, but they are pretty much the same. Ok, I can’t resist, here’s one more:

  • The domain called Business Management Services, after the domain of Process Automation, actually has a service type in it called management of process {why isn’t this in the process automation domain?].
  • The other service types in this domain include Organizational Management [that includes workgroup/groupware and network management, huh?]
  • And Investment Management [ok]
  • And Supply Chain Management [which includes things like procurement, Warehousing, and Inventory Management— so why isn’t this part of back office services, like Finance, Human Capital, and Asset/Material Management?]

If this looks confusing, you’ve got my point, it’s because the FEA SRM is confusing.

- So what’s an enterprise architect to do?

Architecture and Governance Magazine says, enterprise architects need to take back the high ground here—and that must be done in 2007…today’s enterprise architect must re-engage with all the principals in the enterprise by making a case for seeing service and technology architectures as one.”— this is good advice, I suppose, but also more than a little vague!

I’ve seen a bunch of presentations (including a recent one from Department of Education) where EA has tied IT services (pretty much their IT portfolio) to requested business capabilities—again it seems pretty much like what EA is or should have been doing all along, aligning business and technology investments with a focus on reducing gaps, redundancies, and inefficiencies.

I’ve seen other people including some prominent computer and consulting vendors present this topic as well, and aside from pushing there wares, have seen them fall all over themselves tying to define and explain SOA. Honestly, it was pathetic!

Finally, I have seen one impressive implementation at a government agency, and it did actually have savings associated with it, but the application was done a few years back, was relatively small, and there has been little to no movement on further SOA development since (except for the purchase of an enterprise service bus) even though there is a mandate in this agency to implement SOA.

In fact, at a recent meeting with the business side from operations, the presenters said that they were going to spend oodles of money rewriting one (if not the) major operational application for the agency (over 1.2 million lines of code and growing) to make it .NET compliant. I asked the business if they were going to take this opportunity to do this using SOA, and they said no, they just want the same functionality as before!

So in the end, if the business doesn’t want it and the vendors and consultants can’t explain it, the final question with SOA is does the emperor really have clothes?


Share/Save/Bookmark

September 9, 2007

The Peter Principle and Enterprise Architecture

The Peter Principle—Formulated by Laurence J. Peter, the Peter Principle states that "in a hierarchy every employee tends to rise to his level of incompetence." More generally speaking, anything that works will be used in progressively challenging applications until it causes a disaster (i.e. ‘The Generalized Peter Principle’).”

How does the Peter Principle work?

“The Peter Principle's practical application allows assessment of the potential of an employee for a promotion based on performance in the current job, i.e. members of a hierarchical organization eventually are promoted to their highest level of competence, after which further promotion raises them to incompetence. That level is the employee's ‘level of incompetence’ where the employee has no chance of further promotion, thus reaching his or her career's ceiling in an organization…One way that organizations attempt avoiding this effect is to refrain from promoting a worker until he or she shows the skills and work habits needed to succeed to the next higher job. Thus, a worker is not promoted to managing others if he or she does not already display management abilities.” (adapted from Wikipedia)

The Peter Principle demonstrates various human capital issues in the organization that range from performance management to leadership development. While there are no simple answers, there is clearly a need to focus on these issues and for them to be included as part of overall enterprise architecture planning and governance. Perhaps (a far-fetched idea, although one that the military successfully uses) promotions—like new IT systems, products or standards—would be managed through a human capital review board that would catch some of these faulty promotions before they turn into disasters for the employees and the organization.

Let’s add a Human Capital Perspective to the FEA:

To clarify, EA is not only a technology function but is a business function, and as part of the business function, I am calling for the addition of a human capital perspective to the Federal Enterprise Architecture!

Further, while some erroneously consider EA an information or documentation endeavor, it is much more than that—it is a planning and governance mechanism for the organization. And to effectively plan and govern (to execute on mission and achieve success), EA must include a human capital perspective, since people are our organization’s most valuable asset.

In User-centric EA, issues like how to mitigate negative effects of the Peter Principle could be addressed with the addition of a human capital perspective (see usercentricea.blogspot.com posting for 29 July 2007), which would deal with the many behavioral, cultural, and managerial issues regarding human capital facing the enterprise.

A Human Capital perspective to EA would include the following types of information:

  • Professional and management development
  • Leadership development
  • Succession planning
  • Performance management
  • Skills management
  • Training
  • Team building
  • Labor relations
  • Recruiting
  • Retention
  • Morale

I encourage and call for the adoption of a human capital perspective to the Federal Enterprise Architecture (FEA).


Share/Save/Bookmark

August 9, 2007

What can ITIL teach us about EA

The Information Technology Infrastructure Library (ITIL) and User-Centric Enterprise Architecture are both customer driven and focused on providing users what they need to carry out the mission of the organization. Both are about achieving results.

ITIL and user-centric EA look like they compete, but really are mutually supportive. Here’s how:

  • ITIL is a framework of best practices that seek to provide information technology service support and delivery to the end-user; User-centric EA focuses on the end-user and seeks to provide them useful and usable products and services.
  • ITIL looks to match service levels to user requirements; user-centric EA looks to match technology solutions to business and information requirements.
  • The ITIL framework has both a business perspective and an IT perspective — sounds familiar to EA? EA synthesizes business and technology information for enhancing decision making.
  • ITIL looks at all the following: business, applications, infrastructure, security, service, and planning; EA’s views include business, performance, information, service components, technology, security, and develops the plans for these.
  • ITIL is an outgrowth of the United Kingdom’s Office of Government Commerce; EA is rooted in the United States Clinger-Cohen Act and the Office of Management and Budget’s Federal Enterprise Architecture.
  • ITIL provides goals and activities for all types of IT processes including: the management of configuration, incidents, problems, change, service levels, finance, availability, security, capacity, and continuity; EA provides an as-is, to-be, and transition plan for information systems and technologies in relation to performance, business, and information requirements. Both ITIL and EA are looking to enhance mission execution.

At the end of the day, both ITIL and user-centric EA provide a framework and structure for IT to better service the business and its end-users. ITIL will provide for the process side and EA will do the same for the planning and governance.


Share/Save/Bookmark