Enterprise Abstraction

RSS in Plain English

Darren Barefoot posted about this nifty video RSS in Plain English by Common Craft. 

There are two types of Internet users, those that use RSS and those that don't. This video is for the people who could save time using RSS, but don't know where to start.
I love the explanation, as well as the format of the presentation.  Probably not news for most of you, but a useful link when you're trying to explain RSS to people.  The web's not about web pages anymore.

At my organization we'd always talked about producing new technologies at the pace of "web time".  Perhaps we should be striving to get our information out in "blog time" instead?  Visiting web pages one at a time seems so old fashioned and slow these days.  It's amazing how perceptions change.

Periodic Table of Visualization

I was sent a really neat link to a Periodic Table of Visualization Methods.  It's of interest to me as an architect that's always trying to find innovative (and concise) ways to explain complicated concepts.  Whilst we do have a very good and working modelling practice that's based mainly on data flow diagrams (DFD), sometimes it's nice to present concepts differently, particularly if you're trying to converge in a particular direction, or to solicit new inputs.

We're always challenged when we're producing "presentation level" models... in that the somewhat sterile architecture models probably don't always evoke the desired response.  In these cases the standards often go out the window and we attempt to present in most effective (and interesting) way possible.

Explaning Enterprise Architecture

I'm always trying to explain what enterprise architecture is, and why I feel it's important.  Sometimes it's just to explain it to people who ask me what I do for a living, but often it's to sell EA to decision makers within my organization.

Long and detailed explanations are often out of the question.  Most succinct answers don't help.   I need to convey a few key things, but they're concepts that are often mind-bending for those who have not been previously exposed, or those who are caught in a different paradigm.

This diagram is my latest attempt to bridge the gap of EA understanding (click it for a full sized image).  It could use some work... but it's the most succinct diagram of the subject that I could manage.  A possible exception would be Enterprise Architecture = Enterprise Planning... but most people don't seem to fully grasp or accept that.

Comments are welcome as always.

The main thing I think many people miss is the place of EA in the organization.  Many people think that it's about doing technology, or doing technology better.  And while thats true to a point, they don't quite get the high-level up-front, if you will -- Enterprise, nature of the thing.  I always try to explain that it's much more about planning projects and setting directions than about implementing the technology itself.

Well, that said, as an architect my first inclination with propblem solving and communication is to draw something.  Hopefully this will move my clients closer to the target state of better EA understanding.

Complex problem solving

I just found this interesting interactive diagram about the art of complex problem solving.  Lot's of things in the model ring true to me with regard to the architecture field.

It makes me think about times when I've failed to communicate some of my visual models effectively, thus failing to actually communicate the mental model I'd intended in the audience.  When you think about it, it's kind of amazing that we're able to communicate complex ideas at all.

- Via Digg.

Perfect solutions

One of the greatest challenges I face in my daily work is combating the desire to design for perfection.

If a data design, system, or application will not return 100% correct results for 100% of cases the consensus traditionally is that it shouldn't be done, OR, perhaps more seriously, that it's worth the expense of addressing every case.

Now my father's motto was "If you're going to do something, do it right".  I agree with the sentiment.  However, sometimes doing it right does not necessarily mean doing it perfectly.  A sub-optimal solution to a particular problem can often be an optimal (most cost effective and efficient) solution for the enterprise.

I think it's probably human nature that causes this desire for a perfect solution, perhaps combined with the fact that I work in a library.  I get the distinct impressions that librarians self-select for this trait, at least, I've been told this in confidence by some of them.  That said, their wisdom and experience in data management for the kinds of information services we're developing is invaluable.  These guys have been to the battlefront and back, and they've seen it all.

The good news is that I am seeing a trend as our EA efforts move forward, that enable a separation of concerns, and the willingness to accept sub-optimal solutions, and to accept reasonable risks of uncertainty.  The proof will be in the pudding.

SOA and communication with the business

I recently came across an article in CIO magazine entitled The Truth about SOA where they raise the question of communicating with the business about SOA.  The answer they provide is:  don't.

Q: SOA is a technology architecture. How do you make a business case for a new technology architecture?

A: You don't. "Don't talk to the business about SOA because the business doesn't care," says Forrester Research analyst Randy Heffner. The business's interest in SOA extends only as far as it cuts the cost of applications and gets them running faster. But simply rewriting code in the form of a service doesn't deliver those kinds of benefits. To start down the road to building an SOA, there needs to be multiple redundant IT applications that can be consolidated into a single service, or the possibility for multiple areas of the business to use a single service.

I couldn't disagree more.  Let's leave aside the apparent mixing of SOA (business planning as it relates to technology) and web services (a particular implementation technology that happens to complement SOA very nicely), and the narrow definition of SOA as specifically a technology architecture.

You must communicate at least the broad concept of SOA, because in its implementation you're going to change the IT (and possibly) business governance structure substantially.  The business must be involved in this process, and they must understand the implications of moving from (in most cases) tightly integrated silo applications and infrastructure to an SOA environment with all its advantages, and disadvantages.

One of the disadvantages are the potential implications of change and change management.  Someone needs to be responsible for these services, and to ensure that changes and impacts within the business are met.  The must ensure the service levels, extensions to the service, and predict and plan change as the business changes. 

For the business to agree and endorse these changes they must understand some of the fundamentals.  In particular, in my organization, the difference between the presentation (offering) layer, the service layer(s).  For most businesses used to running applications in silos and managing the silo from top to bottom (as a "product") this likely implies a major change -- or at least a consideration -- in the way the business, in addition to the technology, is governed.

Richard just posted on SOA Service Ownership, and some of the specific issues we're having with regard to SOA service governance.

As in most business/technology communication efforts one of the primary issues has been coming up with terms and definitions that we can all agree upon amongst the business and technology folk -- and those of us stuck between.  We've just recently come to a consensus on some of the key terms in my organization.  Perhaps I'll post some of these terms and definitions once they're a little more stable.

Notes on enterprise architecture metrics

I've been getting some hits regarding metrics, so I thought I'd record some of the notes I've made.  These are largely taken from the Gartner EA Summit (21-23 June 2006, San Diego, CA) that I recently attended, and from a few notes here and there in my own practice.  Disclaimer:  I'm still working to get effective EA metrics in place in my organization, so much of this is speculation on my part.

What's the difference between and architect and a janitor?  If the janitor stops doing his job, someone will soon notice. 

-- A joke told by one of the presenters at the summit.

Metrics are an important and elusive aspect of enterprise architecture.  They're important for a primary reason, if you can't prove your worth to the business, then you are not likely to be around for long.  Metrics are also a good way to gauge areas in your architecture practice that are running smoothly, or need improvement.  Further, they're key to a mature EA process.

Sometimes when I think about EA, I consider it simply as the enterprise grand plan.  This is possibly a bit self indulgent, but it's effective for my thinking.  It's like a project where you have a plan to produce desired outcome (deliverables) that meet the original desires.  Unlike a project it is all encompassing (the entire enterprise), often huge, and never-ending.  Never ending is perhaps the key issue.  When a project ends you can compare the deliverables, time and budget expenditures to the original desires and estimates.  Easy.  It's either a success or a failure.  With enterprise architecture, you're trying to measure your success against a moving target... and the deliverables aren't usually as succinct as those of a discrete project.

The best measure of EA would be solid empirical numbers regarding the return on investment for EA effort.  E.g.:  Because of the architecture groups effort that cost $X, the business saved $Y and gained $Z in new business.  These numbers are exceedingly hard to gather or justify in real life.  Was it really architecture that produced this value, or was it more effective project management, business goals, development practice, risk management?   Did we just get lucky?  Without a time machine to go back and run the process again in a control (sans architecture), it's fairly hard to say definitively.

An architecture practice, no matter how good, is unlikely to garner many testimonials from project managers.  I'm waiting for the day when a project manager will report to management that they couldn't possibly have succeeded in meeting their deliverables without architecture, and that architecture reduced the time and improved the quality of the desired business target.  That will be the day.

What I've heard is that architecture is more likely to be regarded as a constraint and a burden, unless it demonstrates (and acts) otherwise.  My goal is to have it at least be considered a worthwhile constraint and burden.  To accomplish this the progress and direct benefits of architecture efforts must be measured and communicated effectively.

During the summit there was a particularly interesting talk given by Deborah Weiss of Gartner where she stressed the difficulty of empirical measurements for EA, but that establishing some comparative and/or non-empirical measures could be useful.  Her suggestions included measurement of:

• improved agility
• shorter cycle times
• ability to extend systems to meet increasing demand
• faster systems operations
• new client system capabilities
• better ability to outsource
• improved ability to seize new business opportunities

More intangibly:

• reduction of risk
• increased customer satisfaction
• improved server/system consolidation

I personally would include some slightly more tangible things, that provide indicators of things such as reuse, reduced costs/times, and business flexibility.  The key point is to demonstrate to the business that it's goals are being met, and are being met better and faster due to a solid enterprise architecture practice.  My suggestions are:

• % reuse of architecture components (especially services).
• the number of the enterprise's strategic goals achieved (as set out by the business in it's strategic plan).
• % of projects that are architecture aligned, and a comparison of the project success based on time, money and deliverable success between these and non-compliant projects.
• the amount of elapsed time and effort to implement changes or new business offerings (a trend that can be tracked over time).
• % of successful projects (track trend over time).
• number of backlogged projects waiting for architecture governance.

The ideas of relating EA metrics to the enterprises strategic plan is not new.  In 7 Essential Elements of EA, the authors describe some potential metrics, and explain the value of relating enterprise archtiecture and business progress.

For example, you can measure the EA for the percentage of strategic capabilities that have been realized (capabilities that are described in the blueprints) and percentage of existing enterprise architectural assets reused by a program. Architectural metrics, used in conjunction with governance, inform strategic planning and portfolio management programs, giving quantification to the return on architecture assets achieved by the organization. They are critical to articulating the benefits of your EA effort and provide the information necessary to help your EA organization provide guidance to the enterprise.

-- 7 Essential Elements of EA, Baker and Janiszewski

Thanigai in his Viewpoint of an Architect: Managing Quality of Service blog brings some important points to the table regarding setting performance goals for EA up front:

...the EA process should come up with the performance goals (for both the business and the corresponding / aligning IT goals) upfront, and then proceed to create the target state solution that will help meet the goals. This way, your solution is aimed towards meeting the goals. And at intervals, if metrics are collected to measure if you're indeed going towards your goal, it helps us correct course of action. There's definite value in this exercise. Otherwise, it is a waste of time.

At my organization we're currently undertaking a serious look at measuring our EA efforts and hopefully I'll soon be able to convey some of the experience.  The observation I offer from  the experience thus far is that it would be wise to start the metrics process earlier rather than later. 

SOA and Agile - Peas in a pod

Brenda posted about the compatibility of SOA and Agile, comparing them to apples and oranges.  I'm not sure of the best metaphor to use, but in my opinion they're undoubtedly compatible methodologies. 

It's human nature to want to 'waterfall' processes.  From architecture to software design and development.  EA, SOA and, of course, Agile, all benefit from an iterative and incremental approach.  Another key practice I've heard applied to both is to, "do just enough, just in time" -- or just in time/agile architecture.

Amongst the strengths of agile methods are the strong assertion that you don't know all the answers up front, that you're willing to accept and embrace change at any point.  These are excellent principles to apply to SOA as well, within reason.  Assuming you're going to start from zero and work out a complete and workable architecture, followed by a representative development and implementation is probably folly. 

Architecture, among other things, is meant to constrain and guide development.  In this regard, EA, SOA and agile should be able to live together harmoniously as long as the architects and developers come to a pragmatic consensus about boundaries and collaboration.  This means having a good working relationship between the two camps, and a good idea of the reasons and methods behind the respective schools of thought.  This, perhaps, is the hardest thing of all to accomplish.  It certainly requires a lot of trust on both sides.

The approach we've taken thus far is to have architecture define a set of well validated services, interactions and general interfaces based on our EA practice, which is directly traceable to business desires.  During implementation we have used an agile methodology to actually construct the innards of the services, integrate, and to build human interfaces and detailed components of the desired system. 

The architects take care to guide the direction, and assert control only over the critical (architecturally relevant) portions.  Usually this means staying at a fairly high level of abstraction. The remainder (the details of implementation, integration, detailed data structures) are left for the designers/developers, and if they choose, an Agile approach.  This works best if the designers/developers and architects will interact as the project proceeds to make adjustments and clarifications as needed.  In this way the architecture, and the implemented system both come closer to meeting the true needs of the business in the end.

I'm keen to hear other opinions in this regard, as admittedly my SOA and Agile experiences are still quite new, and only partially tested in the real world.

SOA explained and defining architecture terms

By far the best introduction for the layperson I've seen on services and SOA is the article What Is Service Oriented Architecture by Hao He at xml.com.  It's slightly dated and get's mildly technical at the end, but it gets the idea across in a single page.   I particularly like the quote (and indeed personal architecture principle):   "Things should be made as simple as possible, but no simpler", by Albert Einstein.  Another excellent resource is the ABC's of SOA by CIO Magazine which is a bit longer, but broader in scope and more up to date.

I don't believe that everyone needs to know how the architecture process works within an organization.  Indeed, if you're running your architecture as a service, then most don't need to know much at all except what goes in (business desires) and what comes out (wonderful excellent plans and implementations that move the business efficiently forward).

I do believe that the business needs to understand the ideas of architecture, including services and SOA.  One of the most effective ways to do that is to define your terms in the context of your enterprise.  Services, web services, business services, product, offer, even client can cause all kinds of consternation and risk.  Particularly if the groups your communicating with not only don't understand the terms, but where each group and individual applies their own meaning to the terms.  Business terms must be understood uniformly across the business.

My humble advice would be:  as early as possible, take the time to sit down with your architecture business stakeholders and define these terms.  Come to a consensus... even make up common terms if you must, but you must all be on the same page with the same nomenclature in the end.  Then, use the terms, and correct mis-usage.  The few minutes spent in the exercise will be worth a complete library of books and papers explaining these terms and concepts, and will be invaluable when you meet next time to discuss ideas.

Ego and Leadership

In James McGovern's post  he describes the need for leadership in architecture and the importance of ego:

With this thought in mind, I would like to figure out how to get enterprise architects to not only have more ego, but to encourage the eliminiation of this practice by evil human resource departments who have gotten the notion of ego twisted...

I agree that leadership is essential for EA to succeed.  I believe that a lack of leadership and process is the reason most architecture programmes are started to begin with.   My colleagues and I try to run architecture as a service to the business.  Where possible, as a humble service to the business.  This was a point driven home to me early in the game, and thus far, it has led to some success.  Much of the service we try and provide is leadership in technology and processes that will allow business to succeed.

A healthy ego goes a long way when you're fighting for a beliefs, principles and processes that are not necessarily well understood within an organization, especially in the beginning.  The setbacks and disappointments that are inevitable when you're pushing some very new ideas can be softened by a healthy ego.  I think that confidence, professionalism, and a forthrightness of attitude and speech go a really long way in this regard. 

A good thick skin does not hurt either.

There are some other qualities that I feel are very important for an architect, including:

• be a knowledgeable generalist.
• have excellent communication skills, you'll use them a lot
• the ability to think logically, and abstractly
• be able to think at both a very high, and very low level of detail
• be comfortable with risk and unknowns

These are the ones that come to mind, I'm sure there are many others.  Some of them can be worked on and improved, whilst others I believe are inherent in a persons personality.  Communication is one of mine that I try to improve constantly, hence one of the reasons for starting this blog.