Gartner’s EA Summit

Last week, I attended Gartner’s EA Summit in Orlando (full disclosure: I was a paid speaker for Progress Software). For an EA guy, it was great to see the general enthusiasm among attendees for the future of EA. The usual “how do I sell EA?” questions persist, but many people are clearly pushing their EA programs to deliver more and more business value, both within the boundaries of IT and across the broader enterprise. Read my more detailed report here.


Making Architects

I ran across an excellent post on The Tech Evangelist entitled “Architecture Frameworks Don’t Make Architects”. I couldn’t agree more with everything he says. It does seem that the industry expects frameworks to help anyone do an architect’s job. The proof lies in the vast range of skill levels among people bearing the title “architect”, with many so-called architects doing little more than maintaining an inventory of existing components and calling it an “as is architecture”.

Frameworks are intended to be tools, not solutions in themselves. My perspective is that frameworks provide two key benefits – similarity of deliverables and their organization, and protection against errors of omission.

A skilled and experienced architect can certainly identify what information is actually needed, in any given situation or organization, to communicate architectural realities and goals. An architect using a framework will be able to create those deliverables and organize them in a way that is familiar to other architects and also to less experienced stakeholders, saving the time of people trying to understand what they are looking at.

Even the most experienced architect can sometimes commit the sin of forgetting an important aspect, especially in situations where other areas are most in need of attention. One of the most useful things about a framework is that it has stood the test of time and become complete enough to serve as a trusted checklist to make sure nothing important is being overlooked.

The really interesting question in all of this is, “How do you develop architects?” The original post suggests that an apprenticeship model would add significant value. While I completely agree, I don’t think that apprenticeship is sufficient. I’ve worked with people who were almost natural architects, possessing a keen sense of system design as they started their careers, and I’ve worked with very effective and seasoned IT people who probably won’t ever be good architects.

The problem, as I see it, is that architects need both education and training, and these are not the same things. In other words, learning a method or process is not enough – you have to have the insight to apply lessons learned in one area to new technologies.

I’d add that we only need to look to other professions with similar issues. Doctors are expected to acquire significant education in the practice of medicine before even starting any kind of apprenticeship, which is also expected. Even the newest apprentice has a solid and extensive foundation based on formal education. Police officers experience a similar approach – formal training in a police academy setting followed by an apprenticeship characterized by partnering with a senior officer.

A major challenge for system architecture as a profession is that very little of this is appreciated by the IT industry as a whole. Surely, there are managers and executives with the insight to understand the value a skilled architect adds to the picture, but I doubt seriously whether this is even a large minority. Too often, we expect people to become architects through informal on-the job training through mentoring by senior architects. Having talked to many in this situation, at both ends of it, and having been expected to train people with little background to be architects, I can tell you that it doesn’t work very well.

So what’s the answer? The dialog in the profession needs to include identifying those critical education elements that position people to be successful architects, and then the specific training and experience that builds on that education. One client of mine suggested that the best way to identify architect candidates was to assemble a team of ten programmers, wait five years, and then it will be clear which one is the architect. He may have been correct, but we need to do better.

This is important to the profession because trying to explain what architecture is and why it matters has proven too difficult – demonstrating value by increasing the number of good senior architects in circulation is much more likely to make a difference. It won’t matter what architecture is when IT leaders understand that they will be more successful if they have good architects involved.

Upcoming ESB Webinar

I’ve agreed to present a Webinar demystifying the enterprise service bus (ESB) for HRInterop on July 15. Registration information can be found here.

The target audience is HR people and IT people working with HR systems. The tone will be introductory, but will assume that the audience is generally familiar with IT and integration concepts. If you don’t know anything (or much) about ESBs and would like to learn more, this might just be for you.

“Operational Responsiveness”

Full disclosure – I’ve been working with Progress Software to help develop and evolve its definition for “operational responsiveness”. Check out the white paper here (and then click on “whitepaper now”).
An intriguing idea, the basic premise being that business needs solutions that have the same characteristics as a pilot flying a plane – the real-time inclusion of the human element to understand and in some cases “feel” what is happening and make appropriate course corrections to make sure established goals are met, or to adjust goals as necessary if that is what makes the most sense (if a plane has a problem or there is an unexpected change in the weather, for example).
You can look at this in different time ranges, too. A business system may need minor changes to adapt to daily fluctuations in the business environment, or more significant changes that require weeks or even months. A great example is to think about a race car – it will include electronic systems that make split-second decisions, a driver that makes both real-time and near-real time decisions, a pit crew that is concerned about tire wear and other factors within the scope of a single race, and a team of mechanics looking to optimize performance of the engine for the next race.
Sounds like agility, but I think it is more than that – agility means the business process and any related systems (and associated development processes) are designed so that changes can be made relatively quickly. Being operationally responsive means having an effective means to determine what changes should be made, not only being able to make the changes quickly.
It is fair to say that many effective business solutions probably fall short in meeting this definition. In upcoming posts, I’ll be sharing some ideas for how to evaluate operational responsiveness and some architectural ideas on how to consistently build it into real-world business solutions.

Designing for reasonable system “life events”

People experience typical life events like graduations, changing jobs, marriage, divorce, and so on. These “life events” are not strictly predictable from the outside, but are not really unexpected, either. IT systems can experience analogous life events, too, and the smart architect would take this into account during both system design and as a general design principle across the enterprise.
This occurred to me recently when a past colleague and I were discussing something they were working on. It seems his company is looking to migrate some existing systems to a different platform, and estimates for the development labor are, well, shocking. Much of this is apportioned to things like manually reviewing and re-writing the thousands of script files used to maintain the application’s databases.

I couldn’t help but be struck by how silly this is – it is probably the case that the existing script files reference resources that will have different paths and names on the new platform. Some level of virtualizing or parameterizing these data up front would have made this effort one of reconfiguration and regression testing, rather than manual review of vast numbers of files.

One wonders whether such a suggestion would have been well received during the early days of the system, when such things often seem like unnecessary and time consuming luxuries that don’t help get the system out the door.
In practice, though, a little up front design work would probably have simplified the creation and verification of every one of the script files over the life of the system. And, after all, “add a new script file” is probably one of the most frequent life events in many systems.

I don’t really know what the precise issues are in this particular case, but I can think of many examples where failure to plan for reasonably expected “life events” created just this kind of problem, and also many examples from my own experience where precisely this kind of planning simplified system development, maintenance, testing, and verification throughout its life. The challenge is quantifying the benefits when you are trying to sell the concept, but it is well worth the effort.

Think you know what users find intuitive? Try buying your computer-novice parent a computer!

A couple of years ago I bought my senior-citizen mother a computer so she could join her friends and acquaintances who were, as she puts it, “in the loop”. Now, she learns about latest goings on among her friends and chuch community through e-mail, browses the Web, and so forth.

My mother’s professional career was equal parts nursery school director and office-based professional, but she had never used a computer before this. I rightly expected to fill the role of help desk, so I chose for her an Apple laptop similar to the one I use at home. It is worth noting that this was not an “anti-Windows” decision as much as it was an “anti-Windows-viruses-and-malware-when-you-don’t-have-an-IT-department-to-deal-with-those-problems” decision. As it is, the Mac does things I have to explain as, “That’s just the way things are with computers.” I currently run a Mac and a Vista machine side-by-side, and the Vista machine definitely has more of these moments than the Mac, sad to say.

I expect to add posts on this topic recalling past events and chronicling those that happing down the road, but it has been a real education for me on two fronts. First, having first used a computer over thirty years ago, my memory of what it means to know absolutely nothing at all was pretty distant. Questions about what I mean when I say “drag the mouse” persist to this day, and we never use the word “file”. Second, so much of what seems intuitive and innovative about both the Macintosh and Windows platforms (I’ve used Windows almost exclusively in my professional life) is actually built around a basic set of knowledge and assumptions.

One such assumption that has been repeatedly challenged is the value of icons. Sure, having a small graphic that consumes minimal screen real estate and also provides useful information is something I find very valuable, but trying to get that information through a phone connection to someone who doesn’t know much about computers is very challenging. The best example is the network status icon on the Mac – it consists of 4 quarter circles, described as either a “rainbow” or “sound waves”. The quarter circles can be black or grey, and you could have just a few black indicating less than full signal strength. Useful, to be sure, but trying to find out what it is telling someone on the phone who may not be looking at the right thing is pretty time consuming.

The lesson from this particular icon experience is this: a text-based diagnostic that can be accessed with a single keystroke would be very useful in this situation. I’m thinking in terms of a dashboard widget (accessible by pressing F12, not some weird multi-key finger acrobatics) that would list a bunch of things under headings, all in text. Picture this – “So, Mom, press F12 and tell me what it says under “Network”. Ideally it would say something like “can access internet and one local printer, e-mail connection has failed three times in the last 24 hours”. But, that is a project for another day.

Anyway, more to come in future posts.


Welcome to my blog, currently under construction, but soon to be populated with all kinds of (hopefully) interesting commentary about architects, enterprise architecture, service-oriented architecture, enterprise software development, and related matters associated with information technology and personal computing.

At various points in my career I’ve been a developer, software engineer, supervisor, senior manager, product manager, project manager, user interface specialist, consultant, IT industry analyst, and most accepted flavors of “architect” within IT (enterprise, solution, information, software, system, business). I am also what would probably be called a “power user” of personal computers, both Windows and Mac, with very definite opinions on what constitutes effective software from a user’s perspective.


Upcoming speaking engagements

Webcast on event processing and service-oriented architecture, sponsored by, recorded the week of October 21.


Presentation on operational responsiveness at Gartner's EA Summit in Orlando, October 7-9, sponsored by Progress Software.


The contents of this blog represent the personal opinions and intellectual property of Larry Fulton, and not those of past or present employers.

Contents copyright (c) 2009 Lawrence B. Fulton