Technology Architecture & Projects

The Enterprise Architecture Definition Collection - Part II

This is Part II of my collection of enterprise architecture definitions. Part I can be viewed here.

It's interesting, at least to me, to get a sense for all the different definitions of enterprise architecture out there. So, over time, I will post other people's definitions of enterprise architecture (and their sources) as I run across them in the literature, blogs, and websites. Updated May 4, 2009.

----------------------------------------------------------------------------------------------------------------------

TOGAF defines "enterprise" as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.

The term "enterprise" in the context of "enterprise architecture" can be used to denote both an entire enterprise - encompassing all of its information and technology services, processes, and infrastructure - and a specific domain within the enterprise. In both cases, the architecture crosses multiple systems, and multiple functional groups within the enterprise.

Confusion often arises from the evolving nature of the term "enterprise". An extended enterprise nowadays frequently includes partners, suppliers, and customers. If the goal is to integrate an extended enterprise, then the enterprise comprises the partners, suppliers, and customers, as well as internal business units.

The business operating model concept is useful to determine the nature and scope of the enterprise architecture within an organization. Large corporations and government agencies may comprise multiple enterprises, and may develop and maintain a number of independent enterprise architectures to address each one. However, there is often much in common about the information systems in each enterprise, and there is usually great potential for gain in the use of a common architecture framework. For example, a common framework can provide a basis for the development of an Architecture Repository for the integration and re-use of models, designs, and baseline data.

The Open Group, TOGAF Version 9 Enterprise Edition Overview. Full text can be viewed here. Thanks to Richard Veryard for the tip to include this. Posted May 4, 2009.

----------------------------------------------------------------------------------------------------------------------

One of the main differences between Enterprise Architecture and IT Architecture is the Business Architecture. The diagram below explains at a high level the purpose of each layer.

Among other activities, an Enterprise Architect will drive, supervise and review technology diagnosis and assessment activities. He will be an active member for the IT Strategy development, identify opportunities for technology-related improvement based on benchmark data and doing high-level cost benefit analysis-(Contribution to the overall alignment of IT delivery to the needs of the business). He will develop the enterprise architecture artifacts including current state architecture, target state architecture, architectural roadmaps, referential architecture patterns and technology standard. Also I recommend he acts as a solution architect during the pre-project and development phases of an IT program or oversight of future state designs including technology, solution, information and business architecture. Other activities are related to the access to the future state architecture for adherence to target state direction, or validate deviation justification and recovery plans.He may develop and implement training and documentation for enterprise architecture processes, procedures and framework, work with a team, coordinate, review and integrate the deliverables of information and technology architects into cohesive solutions architecture, taking into account the user requirements, technical requirements, etc.

Serge Thorn, in his blog, April 21, 2008. I suggest reading the entire excellent post for the complete context of his remarks. Tip of the hat to Mike Walker for the reference. Posted May 3, 2009.

----------------------------------------------------------------------------------------------------------------------

Enterprise Architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model.  Practitioners are called enterprise architects.

Definition of enterprise architecture from Wikipedia. Full citation can be viewed here. This definition originated from the MIT Center for Information Systems Research, Peter Weill, Director, as presented at the Sixth e-Business Conference, Barcelona Spain, 27 March 2007. Thanks to Nick Malik for suggesting this inclusion. Posted June 6, 2008.

----------------------------------------------------------------------------------------------------------------------

An enterprise architecture (EA) is a blueprint that describes an organization’s or a functional area’s current and desired state in both logical and technical terms, as well as a plan for transitioning between the two states. As such, it is a recognized tenet of organizational transformation and IT management in public and private organizations. Without an EA, it is unlikely that an organization will be able to transform business processes and modernize supporting systems to minimize overlap and maximize interoperability.

...

An enterprise can be viewed as either a single organization or a functional area that transcends more than one organization (e.g., financial management or homeland security). An architecture can be viewed as the structure (or structural description) of any activity. Thus, EAs are systematically derived and captured descriptions depicted in models, diagrams, and narratives.
More specifically, an architecture describes the enterprise in logical terms (such as interrelated business processes and business rules, information needs and flows, and work locations and users) as well as in technical terms (such as hardware, software, data, communications, security attributes, and performance standards). It provides these perspectives both for the enterprise’s current, or “as-is,” environment, and for its target, or “to-be,” environment, and it provides a transition plan for moving from the “as-is” to the “to-be” environment.

The importance of EAs is a basic tenet of both organizational transformation and IT management, and their effective use is a recognized hallmark of successful public and private organizations. For over a decade, we have promoted the use of architectures, recognizing them as a crucial means to a challenging end: optimized agency operations and performance. The alternative, as our work has shown, is the perpetuation of the kinds of operational environments that saddle many agencies today, in which the lack of integration among business operations and the IT resources that support them leads to systems that are duplicative, not well integrated, and unnecessarily costly to maintain and interface. Employed in concert with other important IT management controls (such as portfolio-based capital planning and investment control practices), architectures can greatly increase the chances that organizations’ operational and IT environments will be configured to optimize mission performance.

United States Government, Government Accountability Office, "DOD Business Systems Modernization:  Military Departments Need to Strengthen Management of Enterprise Architecture Programs" GAO-08-519, May 12, 2008. PDF abstract can be downloaded here, and the full version can be downloaded here.

----------------------------------------------------------------------------------------------------------------------

The problem is that sometimes its hard to spot the difference between the prat who doesn't understand and is diminishing the importance of technology and the superlative architect who is diminishing the importance of technology because he knows what needs to be delivered but has to get everyone else bought in.

Steve Jones, in his blog, April 4, 2008

----------------------------------------------------------------------------------------------------------------------

An Enterprise Architecture consists of the vision, principles, standards and processes that guide the purchase, design and deployment of technology within an enterprise. An Enterprise Architecture describes the interrelationships between business processes, information, applications and underlying infrastructure for that enterprise, and provides best practices for technology purchase, design and deployment.

Enterprise Architecture structures and processes govern adherence to an organization’s technology strategy and provide a managed environment for the introduction of new technology.

CoBiT Expert, September 11, 2007

----------------------------------------------------------------------------------------------------------------------

In user-centric EA, the impact of mechanistic organizations and bureaucracy is recognized as an impediment to change and growth of the enterprise, the ability of the organization to meet its full operating potential, and the valuation of its people as its greatest asset. EA is dedicated though to unleashing human capability and building a better organization for the future.

How does EA do this? By capturing and analyzing the as-is environment, and formulating a to-be environment and transition plan, EA not only shows the organization where its gaps, redundancies and inefficiencies are, but also facilitates a proactive solution to resolving them.

Further, EA provides two valuable assets to facilitate organizational change. The first is that EA provides business and technical information to all levels of the organization. This information can be used to enable decision-making by all. Secondly, EA provides a mechanism for governance, so that there is a structure and process for enterprise decisions to get made across traditional stovepipes.

By envisioning what could be, rather than just what is, EA challenges the status quo (even a highly mechanistic one) and continues to chip away at it, slowly but surely—working to eliminate stovepipes, build integration, interoperability, information sharing, and an open environment where people can innovate, create, and truly contribute to its success.

Andy Blumenthal, in his blog, August 10, 2007

----------------------------------------------------------------------------------------------------------------------

...The final point of discussion was around the role of education in Enterprise Architecture. The panelists all agreed that experience was a critical factor, and that you can’t teach experience, however there are aspects that can be taught. One panelist gave the example of a course on TOGAF. The one subject that didn’t come up in this or the discussion around the career path to EA was the ability to be a big picture thinker. For me, this is a must have for anyone in the EA role. Enterprise architecture is about the enterprise.  If you can’t see the forest for the trees, you’re going to struggle.

Todd Biske, in his blog, June 12, 2007.

----------------------------------------------------------------------------------------------------------------------

An enterprise architecture is a blueprint that describes the current and desired state of an organization or functional area in both logical and technical terms, as well as a plan for transitioning between the two states. Enterprise architectures are a recognized tenet of organizational transformation and IT management in public and private organizations. Without an enterprise architecture, it is unlikely that an organization will be able to transform business processes and modernize supporting systems to minimize overlap and maximize interoperability.

United States Government, Government Accountability Office, "Enterprise Architecture: Leadership Remains Key to Establishing and Leveraging Architectures for Organizational Transformation," August 2006. An abstract of the work (with links to the full version) can be viewed and/or downloaded here. Posted February 10, 2007.

----------------------------------------------------------------------------------------------------------------------

Enterprise Architecture should never be the goal, it should aim to guide and steer and help to select the good from the bad. This should not be done against some grand IT or technology vision but should be done against the business value that elements will derive. The reality is that this will change significantly over a 5 year period, let alone more, and so any decisions that are made today on the basis of progression towards the mythical enterprise architecture are going to be an increased burden which is done to achieve something that won't happen.

Note here I'm talking about enterprise architecture. If you have a 5 year programme of work to deliver against a new business area or goal than that is fine, because that isn't an enterprise thing, its a solution thing.

Enterprise Architecture isn't a goal, in the same way as IT strategy isn't a goal, the point is that the business changes and IT needs to adapt in line with the business and someone needs to herd the cats to make things consistent. This is why the key skills in EA are not the creation of big documents that try and define some vague future but the ability to influence people and to help them reach the right choice for their current solution that also makes sure that the next thing down the line isn't going to be screwed.

Steve Jones in his blog, January 31, 2007. Updated January 31.2007.

----------------------------------------------------------------------------------------------------------------------

Agile Meets The Recession

It's no secret to anyone about the state of the economy, and the issues organizations face in keeping their businesses stable, including cutting costs. This also leads to the "do more with less" syndrome that project managers are facing on their projects - assuming that they aren't being canceled wholesale along with other initiatives.

Lately, I have been hearing flack from clients and in my Intro to Agile course that I teach at the University of Wisconsin-Milwaukee about two agile methods, pair programming and refactoring with respect to cost and time.

Pair programming is germane to Extreme Programming (XP), but can be used in almost any situation or methodology as desired. The gist of the technique is that while one developer sits at the computer and codes, another developer is looking over his shoulder catching errors and brainstorming with the first developer as the code is being written. They switch roles after a time, and members of the project team pair up with other members after a few days or a week (roughly).

While I am not personally a fan of the practice, I have seen it used fairly successfully in the past on specific projects. The argument against it now, which has come through loud and clear in the past few months is simply this: "We cannot afford to pay two programmers to do the work of one." That pretty much sums it up - the budget is cut to the bone, and the project cannot pay for additional staff to adopt or continue the practice. Not having (or refusing to spend) the cash to support this technique makes all technical arguments in its favor moot.

Refactoring code is being scrutinized heavily as well, particularly if it's "do-over" code that optimizes the system, but provides no new functionality or capabilities for the business or end-users. The argument here is "We cannot afford to refactor working code to optimize it unless it can be shown that there are distinct and immediate advantages/benefits to the business in doing so." Can't say I blame the business and product owners here as well if there is only enough budget to take one pass (or maybe two) at development in each iteration.

There are a number of methods to mitigate such risks, and if you're told the team cannot pair program and/or to keep technical (not feature-related) refactoring to a minimum, you have some choices to make regarding the project.

The primary method to mitigate these risks is to do some design up front. Not Big Design Up Front (BDUF), where artifacts use lots of paper and diagrams to describe a system and take many months to produce (as well as having dubious value to the programming teams). Rather, we do enough design to enable single programmers to write code that requires minimal refactoring or tweaking down the road for purely technical reasons. The thought here is that the time spent on design pays for itself in two ways: reduced staffing cost; and the reduction of technical debt to a point that significant amounts of refactoring are not necessary.

The business may complain that time spent in useful (that is, useful to the development team) design inhibits getting started on development, and we're agile, and we need to get a system up and running quickly. However, they cannot have it both ways - we either spend some time and money on intelligent, useful design, or we spend them on refactoring and higher developer head count during development iterations. I think that some up-front design is a better investment of scarce time and funding than doubling programmer headcount and/or rewriting code to 'optimize' the system without much benefit to the business users.

This line of thought also doesn't address changing requirements, timeframes, and other project uncertainties that are faced every day by development teams and their sponsors. That is a topic for another day, but suffice it to say that as good as Agile methods are in addressing uncertainty through iterative development and small, focused teams, we don't get those benefits for free, and never did.

Architects and Standup Meetings

Many organizations I consult to or are intimately familiar with have embraced certain concepts or 'features' of Agile development while eschewing others - in particular, the daily "standup" meeting where team members transmit and share information with leadership and each other. As I have remarked in the past, these meetings are highly useful when properly facilitated, but are not useful (and perhaps damaging) to projects when not run well with a controlled format.

Oftentimes, an IT architect is faced with supporting multiple iterative projects simultaneously - providing the overall architecture/technical direction to multiple teams working in concert, but very focused on their specific portion - their project - of the overall approach. Of course, leaders for each team have their separate daily standup meetings, and here is where trouble starts for architects in this type of role: they can spend almost their entire workday, every day, attending standup meetings.

I have been in the architect's role on large projects managed in this fashion utilizing multiple project leads/managers/scrum masters, etc. In each case, these folks wanted me to attend their daily standup, and while its great that they consider me part of their respective teams, I decline the invites because once these teams grow past a quantity of say, three, a substantial part of my work day will be consumed in standups - that leave little room to get "real work" done or attend to other important issues.

This also takes into account the fact that a lot of standups go well past the allotted 15-30 minutes for various reasons, are held in numerous locations including different worksites, and generally deal with granularity and minutae that the specific teams are dealing with - code, testing, etc., that don't always need architectural input and direction.

Architects still need successful interactions with these teams on a regular basis - so what to do about it? When talking with project leads and facilitators in such situations, I offer the following:

1. I usually attend specific project standup meetings once per week, and generally speaking, Wednesday through Friday is better so the team has some work completed or in process as the week progresses. Mondays are not real effective because everybody is usually settling in from the weekend.

2. If there are architecture-related impediments or issues that need quick resolution, I'm always available to meet with teams or individual project leads and members as such needs dictate. This is not a standup meeting, but one to resolve issues or impediments, and are focused on those topics alone.

3. When there are architectural work products or issues to discuss, a separate meeting for such topics is required with the necessary attendees invited. From my experience, these types of meetings do not work well in a 'standup' format.

What I am not advocating here is that architects assume an "ivory tower" approach to these issues - becoming pompous that they somehow "grace" a meeting with their attendance and inputs. The fact of the matter is that in the scenario I'm describing, architects' time and efforts must be used prudently, and spending 1/2 to 3/4 (or more) of every day in various project standups is not going to be very productive for the architect spending such time, and the teams trying to gauge where they are on projects and resolve issues as quickly as possible.

Support your iterative/Agile project teams, but know your specific role and apply your time and effort wisely.

SOA Doesn't Change Toxic Human Behaviors, And Their Consequences

Joe McKendrick's paraphrasing of James Governor's remarks about averting the subprime mortgage crisis and subsequent economic meltdown and his further commentary almost convince me that proper application of architecture and technology approaches could have saved the day and kept us from the financial meltdown we're currently in the midst of.

However, there are a couple of problems with that assertion: 1) There was a surplus of capital generated by foreign countries sloshing around the globe looking for a home; and 2) SOA, or any other architectural approach or technology cannot overcome, by itself, human nature - those natures specifically being greed, fraud, and false assumptions, for starters.

The first problem is well-documented and I will make my explanation brief: the US - both its government and people - rang up enormous debts over the past 2 decades that were fueled in large part by the capital provided by countries selling to us, such as China and other far-East countries. We bought, consumed, and consumed some more, thinking that our real estate values and projected economic growth would generate enough income to cover the debt; or that the debts would be refinanced, perhaps multiple times over. As we now know, that was a fallacy, and millions are paying the price.

The second problem, that of the use of any specific technology or techno-functional approach can avert what has happened, is flawed because it fails to address the fact that entities and people will almost always act primarily in their economic self-interest above all. So, if that meant that mortgage broker Bumstead made $500K home loans to people with $35K/year in income because: a) he immediately sells the loan (and risk) and collects his fee; b) he could get away with it; and c) his greed glands are working in overdrive; that's what he's going to do, and as long as the approval process he was subjected to allowed it, the fact that technology existed to somehow mitigate or not approve those transactions didn't matter, never would, and most likely never will.

Why? Because we have to get the processes right first. And any process, no matter how cleverly or completely designed, can be gamed or otherwise abused for adverse purposes - the law of unintended consequences being what it is. While we can reduce greed, fraud, and outright blunders along these lines, we can never completely eliminate them.

I don't think that Joe and James - intelligent guys, both - are advocating that SOA, or any other technology, would have helped us avoid this mess in and of itself. However, it does lend credence to two things: process does matter; and when economic situations arise such as cheap money and outlandishly soaring real estate prices, people are going to behave in ways that feather their nests first, and everything else be damned.

And while technology may mitigate these problems, they will never eliminate them.

We Don't Have Requirements Yet, But How Long Will This Take You?

I function as an EA and project manager, but not both roles at the same time because it's way too insane to try to do both simultaneously. All PMs I work with as an architect know that I am also a PM and teach the subject at the university-level, and my philosophy when in the architect's role is not to give PMs project management-specific advice unless they ask for it or under certain conditions, need to get straightened out and in extreme cases, removed.

One of my current projects is in flux because the sponsors and stakeholders cannot agree on requirements and scope of the project. There has been a continuous back-and-forth between the full-blown project and what is nebulously termed a 'prototype' with reduced features that may or may not become productionalized. Nobody knows at this point.

The full-blown project is also devoid of requirements other than some very broad single-sentence tenets that are not very helpful in developing the system or data architectures in any form of detail. There are no requirements, use cases, or stories to get one's arms around to do a design and data model, much less estimate how long such efforts would take.

So the PM of the project comes into my office and asks me to develop a work breakdown structure (WBS) for the data architecture/modeling portion of this project. For the non-PMs reading, a WBS is, simply put, a list of significant tasks that will be tracked and reported during the entire project. I told the PM that I have produced WBSes for modeling and architecture before, so it should be straightforward to reuse some ones I developed on other projects for this particular one. Then he made a request that I could not comply with: he asked that in addition to the task breakdowns, that I provide a time estimate for each. I refused to do so outright.

As he immediately objected, I asked him: "Where are your requirements?" Immediate heming-and-hawing ensued. He didn't have much (if anything) and he knew it. I told him that any estimate without some direction would be foolish because estimates often (make that always) get taken as reality by management. There was absolutely nothing to base estimates on, not even a swag. I also indicated to him that a major risk-event gets introduced in the project whenever 'estimates' are given on the basis of little-or-no information, or if that information is highly volatile and subject to major changes.

Then, as I suspected he might, he plays the 'Agile' card. "We are running these projects as Agile projects. The requirements development will be Agile also." Nice try, I told him, but while requirements can certainly be added, removed, or changed as the iterations progress, there has to be enough detail up front for the architects and development teams to make reasonable estimates. One sentence 'requirements' are not sufficient for the granularity of the estimations he was asking for regardless of the methods he promulgated. 

A further probing of mine was why he was doing a WBS in the first place - since it's a waterfall artifact - when he claimed the project was 'Agile.' Dead silence. He knew I had him on that too, since he was trying to superimpose a waterfall technique onto the claim of being Agile. He launched on a discourse about how he was going to 'plan' every iteration up front, and deliver to management how many 'iterations' the project was going to take. That almost never works well in any situation, and I advised him that what he was attempting to do was break the project up into phases, not iterations. Not Agile, and not waterfall.

More like disaster - down the road of course. I ended the conversation by stating that when he had a more solidified concept, or 3 or 4, about what was to be built, I would be pleased to assist him.

This conversation happened nearly a month ago, and I'm still waiting, and so is he.

Carnival of Enterprise Architecture #14 - January 18, 2009

Welcome to the January 18, 2009 edition of Carnival of Enterprise Architecture.

Business Process Management

Shahid N. Shah presents Effective artifacts to use on modern WOA/SaaS projects posted at The Federal Architect, saying, "Suvajit Gupta, at The Federal Architect blog, summarizes the recommended artifacts in an agile methodology called SPEED (Streamlined Process for Effective Enterprise Development). He talks about why certain artifacts are necessary for the proper development of architecture and systems."

Enterprise Architecture

Craig Borysowich presents Deliverable: Conceptual Architecture Definition posted at Craig Borysowich.

Mike Kavis presents Top 10 reasons why MDM might be the next dead buzzword posted at Enterprise Architecture & Other Enterprise Topics.

Other

Mateusz Jasny presents Six sigma ITIL - how to reconcile? posted at PMIT.PL Blog.

Mateusz Jasny presents M_o_R - Management of Risk in Organizations posted at PMIT.PL Blog.

Baz Old presents Round Corners With jQuery and CSS posted at Web Development 2.0: Web Design, CakePHP, Web 2.0.

Praveen presents Dynamically Building Java Classpaths from Unix Shell Scripts posted at Unix Simplicity.

Robert McIlree presents Measuring Technical Debt posted at Technology Architecture & Projects.

Mike Kavis presents Did SOA die or do we just suck at architecture? posted at Enterprise Architecture & Other Enterprise Topics.

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.

Extension for 14th Carnival of Enterprise Architecture

I have extended the deadline for submissions to the 14th Carnival of Enterprise Architecture to Saturday, January 17, 2009, with publication the next day on the 18th. You can get further info for submissions here, and thanks!

Time to Get off My Duff...

..and post. I've been fooling around with Twitter and its associated tools for the past few weeks - in addition to working...:)

Hope all had a great holiday and are staying warm and dry!

Happy New Year

My best wishes to my readers and friends for a happy, safe, and prosperous 2009. I'm not alone in bidding 2008 good riddance - although the year went well for me professionally, the current state of the world on many fronts is tenuous at best. I hope and pray that the world has nowhere to go but up at this point.

Happy 2009 everybody - I wish you all nothing but the best!

Lots to blog about, but...Happy Holidays!

I've got a bunch of commentary, stories, and advice stored up just waiting to hit my blog, but as I watch it snow here in Portland (and in Minnesota, and in Wisconsin, and...wherever...:)) I think forward to the Christmas holiday coming up in a few days and the time I will spend with my family and children. All of that can wait until afterward. Besides, the week between Xmas and New Years is always a bit slow work-wise, and with 2009 right around the corner, we get prepped for whatever awaits when the new year comes forth.

That being said, I wish all of you the best this holiday season. Enjoy everything and be safe, and I'll be back after Xmas.