Thoughts on Enterprise Architecture and Project Management

Carnival of Enterprise Architecture #8 - September 27, 2007

Welcome to the September 27, 2007 edition of Carnival of Enterprise Architecture.

Business Process Management

Raj Sheelvant presents Virgin America’s IT Strategy posted at IT Strategy, saying, "Does Virgin America's IT strategy make sense?"

Enterprise Architecture

George Ambler presents Strong opinions weakly held… posted at Architecture and Change, saying, "The phrase "Strong Opinions, Weakly Held" from a post by Bob Sutton describes an important philosophy for architects...."

Jacques Brisson presents Corporate IT Architecture blog posted at Corporate IT Architecture blog.

Aloof Schipperke presents Does IT Hate Itself? posted at Aloof Architecture.

Salman Siddiqui presents Data Center - The Challanges posted at CompuWorld.

Adrian Grigoriu presents The Definition of Enterprise Architecture, revisited (ii) posted at Adrian Grigoriu.

Paul Wallis presents Understanding Enterprise Architecture complexity posted at Keystones and Rivets, saying, "This article discusses Zachman, TOGAF and DoDAF and compares these traditional frameworks with the OBASHI methodology."

Other

Raj Sheelvant presents SaaS in Large Organizations posted at IT Strategy, saying, "Why CIO's for the large organizations resist implementation of SaaS"

Madeleine Begun Kane presents Ode To The Mobile Web (Cell Phone Browsing Humor) posted at Mad Kane's Humor Blog.

Chris Barnes presents Redundant Failover firewall with pf, pfsync and CARP on FreeBSD posted at random utterings.

Cassanova presents The Browser Wars posted at Thoughts of a future engineer.

Paul Wallis presents IT exists for one reason posted at Keystones and Rivets, saying, "This article introduces a concept which I believe will prove to be very important for business and IT in the years ahead."

SOA

Adrian Grigoriu presents The virtualisation of the Enterprise IT posted at Adrian Grigoriu.

Vilas Prabhu presents SOA Fable: Do you wear a watch? posted at Thoughts and experiences of an enterprise architect, saying, "SOA Anti pattern to avoid."

System Architecture

Renata Vincoletto presents > systemcall dot org » Product Development cycle posted at > systemcall dot org.

That concludes this edition.  Submit your blog article to the next edition of Carnival of Enterprise Architecture using our carnival submission form. Past posts and future hosts can be found on our blog carnival index page.

SOA = Sued-Oriented Architecture

David Linthicum asserts that lack of a SOA (or more to the point, a solid enterprise architecture) in publicly-traded corporations could lead to shareholder lawsuits claiming that IT is not, among other things, delivering value due with shoddy (or no) EA - and more to his points in the post, no SOA.

Joe McKendrick, on the other hand, isn't convinced of this, and gives some excellent arguments as to why. While I'm not a lawyer, and I'll wager that David and Joe aren't either, I'm going to go with Joe on this one. As Joe opined:

"The link between SOA and business growth and agility — while bursting with possibilities — has not been firmly established or proven in the mainstream. Even the sharpest lawyers with an understanding of SOA may be hard-pressed to build a case on how a lack of SOA is driving down shareholder value."

Exactly. But wait, there's more: David attempts to equate potential lawsuits driven by SOA/EA failures with those absorbed by the accounting/auditing profession after the Enron, WorldCom, and Tyco debacles - which led to the passing of the Sarbanes-Oxley Act (SOX). There are more than a few problems with that argument, and the first issue, is: accounting and auditing standards are codified, and SOA and EA are most certainly not.

The EA community does not have an accepted framework like GAAP (Generally Accepted Accounting Principles) to use in providing precise guidance, procedures, and precedent in such matters. Without a commonly accepted foundation like this, I fail to see how anyone, no matter how astute, could convince a jury that they be recompensed for 'losses' that they cannot reasonably prove by the presence or absence of SOA, or an enterprise architecture for that matter.

Next, a litigant could potentially make the argument that EA was practiced in a shoddy manner (or, as the case may be, not practiced at all). Nice try, but let's look at the accountants again - in addition to GAAP, there is the CPA credential, of which those holding the designation are deemed reasonably competent to practice accounting, and must follow GAAP. CPA's that do not follow GAAP leave themselves wide-open to litigation or other sanctions, in part similar to the scenarios David provides. What do we have in place for enterprise architects and SOA practitioners? We all know the answer to that question, and so do astute attorneys. Bottom line: no dice in court of law on that tactic, at least currently.

A commenter to David's post states that IT is viewed as a cost center in most organizations, so how could this matter from a shareholder-lawsuit perspective? That assertion is generally true, and because of it, a defendant company could reasonably assert that any "ROI" claims made, by anyone, aren't valid because IT is not in the revenue/profit-making side of the business. I find most ROI claims on IT projects to be, at best, of dubious, non-evidenced-based value because of the imprecise and/or misleading nature of measuring ROI in such cases. Judges and juries have a difficult time with claims that cannot be easily proven and substantiated.

Finally, if all of these purported vicious shareholders out there want to sue because of IT failures related to SOA or EA, there may be better low-hanging fruit than this for the shareholders and their barristers to feast on. Why not sue companies for lousy project management? Or inept software development? Or crappy IT operations?  More importantly in any of these disciplines, how does this gets proven in court to secure damage awards and should/can it be?

The bottom line here is the potential liability for a shareholder lawsuit based entirely on an organization's IT strategy, or lack of it is, at best, disingenuous given the current state of our profession. I wonder what other motives are at play here in making such assertions. I don't think I have to elaborate on that if you're thinking the same thing that I am.

Gave the blog a facelift

As you can tell, I did a bit of updating and housecleaning on the blog today. Was tiring of the previous design and wanted the text to be displayed a bit larger with more contrast in the background...so here's what I chose off of the palettes that Typepad furnishes its members.

Enjoy!

Carnival of Enterprise Architecture #8 - September 27, 2007

The 8th Carnival of Enterprise Architecture that I host through Blog Carnival is coming up on September 27, 2007, with submissions due by September 26, 2007. If you have an EA- or IT-related post that you'd like featured through the Carnival, you can submit the Permalink URL and related information here.

This is a very easy and effective way for EA and IT bloggers to get their messages across to a wider audience, and I hope that EA and IT bloggers will consider submitting their best pieces (or those of others that they particularly like) to the Carnival.

A few pointers for article submissions to the carnival:

* Off-topic material, pitches for products & services, and content spam will be not be published. Every month, I delete between 5-10 pieces of obvious spam, vendor ads, and off-topic material prior to publication. Please don't waste your time or mine and thanks in advance.

* Feel free to nominate blog posts of others for the Carnival, but make sure to identify the author!

* Material posted in previous editions of the Carnival will not be re-published, regardless of who submitted it and when it was originally submitted.

Again, the deadline for submissions is September 26, 2007, and the carnival will be published on September 27, 2007. I look forward to your contributions!

Nailing Powerpoint and Presentations

Seth Godin isn't Edward Tufte (and if you don't know who Edward Tufte is, it's a very positive move to acquaint yourself with this awesome guy's books and website pronto), and he nails it again on effective use of Powerpoint in presentations.

Powerpoint isn't evil, but it's abused a lot. Drink in what Seth and Dr.Tufte prescribe. I have, and I feel much better about my EA and PM presentations, and the results have been much better than I expected over time.

[Fill-In-The-Blank] Enterprise Architecture

Sifting through the enterprise architecture blogosphere of late, one finds a number of commentators advocating EA with an array of qualifiers in front of the term "Enterprise Architecture." As examples, we have "user-centric," "practical", and "pragmatic" enterprise architecture connoting that the qualifier in front of "enterprise architecture" denotes a greater level of goodness or completeness than if the qualifer were not present. Before I continue, let me state on the record that all three of the blogs that I just referenced above contain posts that are well thought-out and written even if I don't agree with everything they espouse (and I do agree with the majority of the insights they present).

Call me a nit-picker if you must, but putting limiting or obvious qualifiers in front of a term like enterprise architecture doesn't really add much to describing a discipline that is already ambiguous in its own right. Also, some qualifiers can bring about unintended consequences from those who are confused or feel that their interests or goals are not adequately represented or accounted for.

Let's take user-centric enterprise architecture as an example, since I don't think that any of us walk around our respective organizations all day espousing the concepts of "impractical" or "dogmatic" EA...:) On the surface, why wouldn't we all want user-centricity? It makes people feel like meeting their needs is the top priority of the IT architecture, and that's certainly a noble and worthy goal. However, if that's all that there is to this concept or "non-users" are not being taken into account in this approach, there will be massive amounts of trouble. Consider:

• Enterprises typically have thousands of users, and a lot of their operational systems provide services for and to these hordes. It is impossible to gain consensus from such a massive body, much less design and deploy a "centric" architecture around them.
• A substantial portion of operational systems within the enterprise run independently from users. These systems are definitely a part of the enterprise architecture, so how exactly is user-centric enterprise architecture addressing these systems and the issues they bring to the table?
• As good as the terms "user-centric," people-oriented," and "people over process" sound in their respective altruistic intents, the fact of the matter in large enterprises is that the organization and its processes outlast everybody, regardless of who they are. A "user-centric" architecture must deal with the fact that the "users" (and their respective and divergent viewpoints) are going to get swapped out - often. And far more often than the processes the organization uses to conduct its affairs.

Enterprise architects already have huge issues serving and maintaining relationships with various constituencies both within IT and the business. Attempts to further qualify EA such as I've described above usually serve to skew the messages we're trying to send to these constituencies, and most often in a negative way with respect to work products and eventual outcomes.

There is one more term used to qualify EA and lots of other IT and business issues that needs to be addressed in a similar manner: agility. However, that deserves a post all its own and it will be coming later on this week.

Funding Enterprise Architecture Efforts and Why It Matters

Funding models for enterprise architecture are an indicator as to the status and effectiveness of EA efforts within an organization. How EA is funded reveals much about levels of EA practiced and what the results are (or will be) in organizations using the discipline. I've been searching for and reviewing research and commentary on how enterprise architecture is funded in organizations, with a goal as to gaining some insight between specific funding mechanisms/models and success or failure of EA efforts.

Below are 3 common funding models that I've seen in actual practice:

1. EA is funded on a per-project basis: Every project allocates budget and resources for EA directly and exclusively of other projects or the IT and business organizations as a whole.
2. EA is funded via a 'tax' on projects and operational systems: All projects and operational systems pay a fee, or 'tax' as a percentage of their budgets to fund EA initiatives, with the EA effort and resources serving the entire organization.
3. EA is funded as a capital expense out of the overall IT and/or business budgets exclusive of specific projects, systems, or lines of business.

There are, of course, other models and hybrids of the above, but I'll stick to these three to start. Each of these models has strengths and drawbacks, and the purpose of this post is to call them out for your review and comment, and not necessarily to advocate one over the other.

FUNDING ENTERPRISE ARCHITECTURE ON A PER-PROJECT BASIS

In this model, every project plans and accounts for EA costs and resources on its own, exclusive of the planning, budgeting, or use of EA services and resources by other projects within the organization.

Advantages -  Tighter cost control, resource utilization, and flexibility/agility. Projects have the option to only use "enough" EA (including none) to satisfy their needs and requirements.

Disadvantages -  Several, including: no motivation or perceived need to coordinate EA efforts across the organization; failure to utilize EA to 'save money/time' or to control scope;' governance issues; increased operational costs from design and implementation execution differences across projects (silo architectures --> silo systems developed); no accounting for operational systems (i.e. few or no projects underway, no EA funding);

FUNDING ENTERPRISE ARCHITECTURE WITH A 'TAX' ON PROJECTS AND/OR OPERATIONAL SYSTEMS

This model is shares similarities with the classic IT "chargeback" model, where all non-IT parts of the organization pay out of their budgets for IT services. All project and operational budgets are assessed a fee for EA services whether they utilize them or not (and that's a separate, but important issue in it's own right), usually as a set percentage of the project or operational budget for all systems being developed or in production.

Advantages - almost guaranteed revenue stream from budgets, since all projects and systems provide funding to some degree based on budget or other metrics; inclusion of EA on all projects

Disadvantages - specific demands for services in direct proportion to a project's "investment" in EA, whether justified or not; complaints and/or negative actions from the business or IT project managers about having to "pay for EA" as it is perceived by them as a "waste of money;" dissatisfaction with EA efforts relative to the costs incurred.

FUNDING ENTERPRISE ARCHITECTURE AS A CAPITAL EXPENSE FROM IT AND/OR BUSINESS BUDGETS

Enterprise architecture is funded as a set, capitalized expense from the overall IT budget and is not directly dependent on the budget of specific projects or business initiatives.

Advantages - guaranteed revenue stream (at least for the current fiscal year); EA is not beholden to the whims of specific projects as with "chargeback" or ad hoc funding models described above.

Disadvantages - like training, easy to drop from fiscal budgets in times of cost cutting - whether justified or not; tends to promote "ivory tower" syndrome if EA's have no accountability to the business or to other IT staff; requires yearly justification to CFO or CEO if results achieved are not in-line with business' expectations.

If anyone has other stories, models, or insights they'd like to share on this, I'd love to hear them. I'd also like to hear about the ways organizations measure the effectivesness of EA budgets/investments. If anything, such metrics will give perspective on how EA is viewed organizationally, because everybody, myself included, has an opinion about getting "one's money's worth" when spending their budget dollars.