Enterprise Architecture: Galactic Everything.
What can’t you include in these two words: Enterprise and Architecture? Over the past few years there has been a huge emphasis on innovation, and with it, a focus on new business models. Eventually, this leads to line of business managers talking to the technical arm of the company for ways to implement the new processes, functions, and capabilities. Whether you call yourself an analyst, project manager, architect, or something else, if you sit between the vision and the reality, then you are involved with modeling and modeling frameworks.
Whose View of the World?
Maybe you use the Zachman Framework, or TOGAF, or Catalysis, or MDD, or Michael Porter, or Business Scorecard. Maybe you go back to the 1960s, with Peter Checkland and Soft Systems Methodology, or are a fan of the Rational Unified Process. There are frameworks that focus on views and perspectives from a technical standpoint, or organizational development, social change, construction and problem solving. They all fight for a balance between simplicity and the tendency to elaborate one more level. Do you use a telescope or microscope? Do you crank it up or down one level? Do you bother to include society, culture, and economics?
Can It Fit in Your Head?
Whatever framework your company or customer might be using, keep in mind some simple rules of thumb. First, the point of building models is to communicate. This means you need to consider who is looking at the model, what you leave in or take out (elided), and how well your audience can in turn communicate it to someone else. Second, remember the studies that show our brains can only handle a handful of items at a time (The Magic Number Seven ). Third, do not try to get it all on one piece of paper. Think of an architect building your house, and the fact that he has a set of plans with each sheet depicting a particular viewpoint for wiring, plumbing, landscaping, etc. For each picture, diagram, artifacts, work product, or exhibit, justify its creation by its intended use for this particular project.
All of this means you do not ask your client or organization to deliver your particular framework or model to you on your first day (as I have to confess, I tended to do in my early years). Instead, try to tease out the things they use and refer to. Ask what pictures, diagrams, charts, or reference material they find essential when talking about the problem being addressed. Don’t try to vacuum cleaner up all of their information from a raid on their file cabinet and a quick peppering of questions where you try to suck their brains out. Instead, take a lesson from other agents of change in organizational development, consulting, and even psychotherapy and take time to build collaborative models together. Yep, that’s right, roll up your sleeves, grab a marker, and take more time than you thought you needed to find out ‘what they mean by that’, ‘what happens next’, and ‘who cares about this?’. Keep a simple framework in your head and start with things like financial, logical, and physical aspects. Elaborate from conceptual to more specific and concrete as you need. Don’t forget to focus on context and end results as barometers. Oh, and test models with subject matter experts, constituents, end users and implementers along the way.
How does relate to System z?
Well, I was cleaning through some files and ran across examples of both cases where systems were designed with very narrow scopes, and those, like enterprise class System z solutions, had larger perspectives, and did things like lasting better over time, scaling better, and ending up costing less in the long run. Naturally, I started to think about some things that characterized the design of those solutions. Today, when divisions and applications and infrastructures are being called on to be more efficient, and integrate together more effectively, we are all being called on to evolve a ‘brown field’ solution architecture to its next incarnation. If you are involved in leading that change, please remember that most projects still ‘fail’ against their original objectives, most requirements are gathered incorrectly, and that it’s incredibly easy to get lost in detail or jargon and fail to communicate across the business and IT chasm effectively.
Where to start…
Sme good thought frameworks I have personally found useful, that you may not have run into, include Ellen Gottesdiener (Requirements by Collaboration), David Sibbet (Graphic Facilitation and Process Methodology of The Grove), Peter Checkland (Soft Systems Methodology) and of course for business models there is always Michael Porter, Balanced Scorecard's Kalpan and Norton, and Eric Helfert for insights to financial frameworks. Look for approaches that organize large, complex systems in other fields -- you might be surprised what can be leveraged.[Read More]