Todd Biske: Outside the Box

Archive for the ‘Enterprise Architecture’ Category

James McGovern asks, “Are folks who are left-handed smarter?” Well, since I’m right-handed, my answer should be no. But then again, I don’t view “handedness” as an absolute, but rather a continuum. There’s a lot of left handers in my family, as well as a certain amount of ambidextrious behavior. I can do several things left-handed (although writing isn’t one of them).

Anyway, James’ post reminded me of an observation that a former boss made once. He was wondering whether there was a correlation between musical ability and technical ability. He noticed that nearly all of our strong technical guys had some talent in music, whether it was singing, playing an instrument, composing, etc. While we never tested his hypothesis, it’s still very interesting.

I’ve always been interested in psychology, social dynamics, etc. and one of the interesting things that I’ve thought about in my own life is how I wound up in the College of Engineering at the University of Illinois, something that most people would associate with a “left-brained” mentality, while my brother went on to become an artist, including a stint with Disney Feature Animation until they closed the Orlando studio, a very creative “right-brained” discipline. The common thread between us, at least in my opinion, is that we were both able to bring thinking associated with the other half of our brain into our daily work. In my brother’s case, one thing he’s been complimented on is his ability to create precise illustrations, etc. without the use of a reference. I can only surmise that his “left brain” analytical skills have something to do with this. In my case, while I am very analytical and logical, I’m also a very big picture thinker, a “right brain” activity. Interestingly, musical ability is associated more with “right brain” thinking.

So, if the hypothesis holds, the best people are the ones that are able to use both parts of their brains effectively. It is certainly a possibility that left handers are able to do this more often because of having to live in a right handed world, so they’ve always had to use the other half of the brain, whereas most right handed people have not. Who knows, but it’s fun to ponder.

A previous post discussed how no two organizations seem to define the role of the architect the same way. It just occurred to me that the same thing holds true for another common deliverable of the enterprise architect: the reference architecture. I’ve had the opportunity to work on a few reference architectures with a few different companies and I can certainly say that no two were the same, although there was certainly commonality between them.

There are at least two questions that have come up in multiple efforts. The first is whether or not a reference architecture should recommend specific technologies (e.g. “if you meet these conditions, you should use vendor product MagicFooBar”) or only describe the capabilities required, leaving implementations teams to choose a technology that fits (e.g. “the services tier must be exposed using XML-based interfaces”). The second question is one of depth. How much guidance should a reference architecture give? Should it go so far as to place constraints on how individual classes are named, or how the file hierarchy is set up in the source code repository? Or should it remain at a level somewhere above the design of individual classes? It may seem simple at first glance, but I can speak from experience that once you start providing some guidance, it’s very easy to get pulled into the depths.

What’s the right answer to these questions? I don’t think there is one. Why? Because reference architecture is about guidance, and the guidance needed in any one particular organization is going to be dependent on the skills of the staff, the organizational structure, the technologies involved, the problems being solved, etc. So what do you do? In my opinion, a good course of action is to focus on delivering guidance that is singular in purpose, at least within a single deliverable. What does this mean? It means that you should avoid trying to answer all of the questions within a single (and likely very large) document. Rather, each deliverable should start with one simple question, and focus on answering that question clearly. For example, rather than having one big reference architecture that attempts to cover all possible business solutions which could easily include web UIs, desktop UIs, mobile UIs, workflows, services, automated processes, applications portals, content portals, collaboration portals, and much more, consider having a separate document for each one, forming essentially a hierarchy of documents. The earlier documents discusses things more broadly, intending to answer the question of what collection of technologies are needed for a solution, but not necessarily guidance on the appropriate way to use that technology. For that, once the decision to use a particular technology has been made, a separate document goes into added depth, and the process continues. The reference material will eventually work its way down to development and operational guidelines (or hook up with those that may already exist).

Of course, all of this is easier said than done. It’s not easy to determine the “right” hierarchy up front. Again, the litmus test to apply is whether the document has clarity and singularity in purpose. If you find yourself with a document that starts getting onerous to use, consider breaking it apart.

What are others thoughts on this? As always, this is simply my opinion (after all, this is my blog, so that’s what you’re going to get), but I also am always interested in the thoughts of others and striving for a more collective wisdom. What has been successful for you when trying to provide reference guidance to teams? What hasn’t been successful? Use comments or trackback.

Update: I was just checking my feeds and there were two others blogs that discussed reference architectures: this one from George Ambler and this one from Simon Brown. Enjoy.

One thing that I have noticed over the past few years of my career is that no two companies define the role of the architect the same way. Personally, I view this as neither good nor bad, and this isn’t going to be a post on the whole architect certification efforts that exist out there. While it may make it more challenging to find qualified candidates when the definition of the role changes from company to company, once you’re in a company, clarity of the specific responsibilities at that company are certainly more important than whether or not you’re doing the same work as Joe or Jane Architect down the street. As another aside, I also think that those job responsibilities should serve as a guide, but not a barrier. All organizations require some flexibility in what people do if they expect to get things done versus devolving into a finger-pointing episode of people saying, “That’s not my responsibility.” Which brings us to the first type of role.

The Gluer

In this role, the person with the lucky fortune to have the architect title is expecting to hold everything together from a technical perspective. A typical software development project involves far more technical tasks than just writing code. Servers may need to be built, software installed, routers configured, etc. Put simply, the person playing this role was expected to be the glue that holds everything together from a technical perspective. You’re probably asking, “Isn’t this the job of the technical lead?” Well, the problem with the technical lead is that in most organizations I’ve seen, it was purely a role, and not a job title. Therefore, it was difficult to actually know who the technical leads were in an organization, get coverage across all projects, etc. Titles like senior developer or lead developer don’t cut it, because the emphasis is still on development, and not the other tasks involved with getting something into production. Unfortunately, giving them the title of architect is problematic. While it does allow an organization to establish some clear technical leadership, it’s likely that the individuals with this title will be so consumed with tactical project decisions, that very little of their time will actually be spent on architecture.

The Scheduler

While I never would have guessed this one, I heard it mentioned at two different organizations that architects are supposed to act as project managers for technical activities, normally working in conjunction with the “real” project manager. While I do think that all leaders should have some ability to do basic project management activities. That is, break down a goal into some set of constituent tasks on a timeline. There are certainly ties back to the gluer role, as this essentially takes the technical leadership a step further. In addition to identifying all of the technical activities, the person now has to manage all of them, rather than delegating this back to the project manager. Of all the roles, this one is the least desirable to me because I don’t consider project management a strong point for me. I’m admittedly a big picture thinker. Most good project managers I know are extremely detail-oriented. The best working scenario for me personally, is not to have me be the project manager, but work side-by-side with the project manager.

You’ll notice that both of these roles are very project-specific. If all of the architects in your organization are on project assignments, that’s a problem. Project, or solution, architecture is important, but you also need architects outside of projects, hence the next two roles.

The Decision Maker

This architect is normally not assigned to projects, but is still involved with the decision making process within projects. This person is likely viewed as the top of the technical hierarchy within some organizational or technical domain. If it’s associated with software development, I typically see it following organizational boundaries (e.g. an architect for all solutions developed by one development organizationy), while on some of the other activities, it follows technical domains, such as a Security Technology Architect, a Networking and Communications Technology Architect, etc. Projects go to these architects when decisions need to be made or approved. The challenge I’ve seen with this role is the flood gate, especially when the title is first established. Many organizations don’t have a technical hierarchy in their organization, and as a result, it can be unclear as to who has the technical decision making responsibilities. As a result, when someone is granted the title, the flood gates open, and every technical decision, even those that should be no brainers, wind up coming to those deemed “architects.” The challenge here is that the architect winds up having all their time consuming by decision making, with no time left over for establishing a strategy and direction.

The Strategist/Policy Maker

At the opposite end of the spectrum from the decision maker. Architects acting in this capacity are the legislative branch of the government, focused on established reference architectures, policies, roadmaps, etc. I thought about breaking this into two roles, because there are plenty of architects who don’t do strategy, but in general, the perception of the enterprise is similar. There’s a significant risk of becoming an ivory tower in this role. Just as the decision maker gets sucked back into project activities, the strategist can become disconnected from the reality of projects.

So what’s right? Personally, I think an organization needs gluers, decision makers, and strategists. We already have project managers, and as I previously stated, I don’t think we need to break out “technical” project management as a separate discipline. Should the remaining roles all have the “architect” title? In my mind, there’s really only debate about one role, the gluer. Clearly, not all of the activities associated with technical leadership have something to do with architecture. At the same time, however, if it’s not clear whose responsibility it is, these technical concerns will bubble their way up to the “decision makers.” If it’s necessary to bless that role with a title like “Solution Architect” to avoid this scenario, then do it.

What other roles and responsibilities have others seen with architecture? What’s missing from the list?

James McGovern called out that he hasn’t seen much discussion on the topic of reference architectures, and called me out for my thoughts. I’m never one to pass up a good blog topic, especially when I don’t have to come up with on my own.

First, some background on my experience. My current job responsibilities include the development of reference architectures, my engagements with clients while I was a consultant all included the development of either a deliverable that included “reference architecture” in the title, or was clearly some form of reference material, and my job prior to consulting, included the development of reference architectures within the last 12 months of my time there. So, I’m no stranger to this space.

Reference architectures, and reference materials (since the need doesn’t stop at architecture) in general are an interesting beast. Personally, I view them as part of the overall governance process, mainly because they’re created to document a desirable pattern or approach that the authors would like (or will ensure that) others follow. At the same time, a document alone does not create governance, just as buying an SOA Registry/Repository doesn’t create SOA governance. Reference materials are a tool in the arsenal and the degree to which they are used is dependent on how you architects work with the end consumer of the reference material. Organizations are all over the spectrum on this. Some architects live in an ivory tower with virtually no interaction with teams on active projects, some architects are the exact opposite, with their time completely consumed by day-to-day project activities. Most organizations fall somewhere in between.

My opinion is that reference material is absolutely necessary, if nothing else but to prevent the organization from tribal operations. If none of the standards and guidelines ever get written down, and decisions are solely based on tribal knowlege, the organization can quickly break down into the haves and the have-nots. If you’re part of the tribe, you have the knowledge. If you’re not, all you can do is make your best guess until you have to show up to tribal council and get lambasted. Trying to gain the knowledge from the outside is a very difficult process.

The next question, however, is what information belongs in the reference material? Does it do any good to document something in the reference architecture that everyone should already know, or should you assume that no one knows anything, and document it all? The problem is that EA has limited resources, just like everyone else, so you have to give consideration to the bang for the buck in the reference material. Once again, what’s “right” is very dependent on the end consumer of the material (which is why having a consumer focus is important). If you have an organization of seasoned Java programmers, how much reference material is needed on developing good web applications? If you have an organization with lots of VB6 and COBOL developers, they may need lots of reference material on web applications. So, know your audience, and make sure that the reference material is relevant and valuable for them.

I had the opportunity recently to learn more about the role of internal audit in an organization. It was a very interesting and educational experience, and got me thinking a lot about the relationship between the two.

What’s the visual that comes to mind when we hear the word audit? People in the USA probably think of an audit by the Internal Revenue Service. They would also rather go to the dentist and have a root canal done without anestesthia than be audited. So, you can certainly argue that the internal auditors have their work cut out for them. The presenter pointed out, however, that the role of internal audit is changing with time. While a few years ago, they may have been viewed as a reactive police force, today, there’s a shift toward a proactive consulting organization. Rather than coming in after the fact and telling organizations whether they’re compliant or not, they’re now being asked at the beginning, “What do we need to do to make sure we’re compliant?”

There are strong parallels to what goes on in the world of enterprise architecture. First off, many organizations have the dreaded architectural review board, the reactive police force of architectural governance. Projects teams dread them. Somehow, we need to move from this model to the latter model where projects teams know they need to be architecturally compliant and are actively seeking out the input of enterprise architecture to ensure this is the case from the beginning.

Unfortunately, the challenge for Enterprise Architecture is that there is no corporate mandate for EA in the same way that there is for Internal Audit. While I personally thought David Linthicum’s posts on EA as a corporate responsibility were a big stretch, you could certainly argue that if enterprise architecture was a corporate responsibility in the same way as Sarbanes-Oxley, then there would be no debate on whether an organization needed Enterprise Architecture. I found it very sad that at the Gartner EA Summit closing session, when Gartner posted a predication that 40% of EA programs will be stopped by 2012, about 40% of the audience agreed. Note that prediction didn’t say “changed” or “restarted,” it said “stopped.” A publicly listed organization on the NYSE can’t stop the Internal Audit program, it is required.

Overall, my takeaway from this session was that EA and Internal Audit need to be best friends. If Internal Audit has an IT audit group, which most do, it needs to be working closely with the EA group, as both are providing governance. In one of my panel discussions at the Gartner event, I made the comment that EA is certainly about governance. It could be argued that EA activities are basically centered around two major activities: strategic planning and governance. While Internal Audit probably has less of a role in strategic planning (except where governance issues are necesseary), clearly, there’s significant overlap in the governance function. Determine how both groups can work together to ensure that projects aren’t bombarded with governance from multiple groups. The view of the governed is already very negative, we need to do what we can to change that view.

James Urquhart brought to my attention the public review of SOA Patterns, as authored in the forthcoming book, “SOA Design Patterns,” by Thomas Erl. You can see the press release from Prentice-Hall here.

My first reaction when I received the email, prior to visiting the SOAPatterns.org site was one of skepticism. While I think patterns can add a lot of value, the immediate problem I saw stems from the fact that I’m very much a believer in business-driven SOA. In order to reach a broader audience across multiple verticals, you have to be more business agnostic. As we get more business agnostic, we naturally move deeper into the technology stack, and things at that level of granularity may not be the best service candidates, although they may be great candidates for reusable frameworks. If we’re talking about patterns inside of the service implementation, then we’re really talking about general design patterns, building on the original work of the Gang of Four, not really SOA Design Patterns.

So, with my bias set, I visited the web site. The first thing I hoped to see was some classification by business industries, such as “SOA Patterns for Insurance” or “SOA Patterns for Health Care” but I didn’t find them. Bummer, but I also didn’t expect this. Something like that would be of significant value as intellectual property to a consulting firm, and I think they’d make a lot more money keeping it to themselves and leveraging it on their engagements. What was on the site was four chapters: Basic Service Inventory Design Pattern Language, Architectural Design Patterns, Basic Service Design Pattern Language, and Service Design Patterns.< ?)>

In looking at the first chapter, Basic Service Inventory Design Pattern Language, my first reaction was again one of skepticism. The first page begins with “Inventory Context Design Patterns,” “Inventory Boundary Design Patterns,” “Inventory Structure Design Patters,” and “Inventory Standardization Design Patterns.” It also introducted a phrase- “service inventory architecture” -which I had never heard before. Looking at this page, nothing was making a connection with me. As I drilled into each section, I did find some goodness, but it could be argued that what is really being presented in this section is really a description of a step in a methodology, rather than a pattern. For example, one pattern listed is the “Enterprise Inventory” pattern, which lists the problem as:

Delivering services independently via different project teams across an enterprise establishes a constant risk of producing inconsistent service and architecture implementations, compromising recomposition opportunities.

The solution is:

Services for multiple solutions can be designed for delivery within a standardized, enterprise-wide inventory architecture wherein they can be freely and repeatedly recomposed.

This doesn’t feel like a “pattern” to me, but it’s certainly something that should be done. I don’t think anyone would argue that having an enterprise service inventory is a bad thing. Another pattern I looked at was the “Vendor-Agnostic Context” pattern. Again, what was presented in the “pattern” was goodness, however, it felt more like a principle rather than a pattern. This particular one did do a good job in demonstrating how this principle does lead to the use of specific techniques, such as leveraging the “Canonical Protocol” and “Decoupled Contract” patterns.

Overall, what did I think? Well, it certainly didn’t meet my original hope of seeing industry-specific business patterns. By that, I mean I didn’t find something that said “Order to Cash” with guidance on the types of services that should make up that process. I didn’t find something that said, “here are services that all organizations with an HR department should have.” Nothing business-specific whatsoever. Of course, I didn’t expect to see this, it’s just what I was hoping to see, just as I hoped the (defunct?) SOA Blueprints effort from OASIS a couple years ago might produce something along these lines.

Putting that bias aside, the more I dug into the site, the more I found things that provided good guidance, even though I’d say the use of the “pattern” moniker was a bit liberal. If you want to get an idea of what principles and factors should be considered in creating good services, versus just slapping WSDL or XML schemas in front of some existing logic, there’s a lot of good material here that is freely available. While some of the earlier pages read too much like a college textbook, a couple drilldowns brought me to things that were applicable to my daily work and made sense. So, based on that, I would recommend that people at least visit the patterns site, drill down into it, and see what nuggets you can leverage in providence guidance to your service development teams. If you really like it, then perhaps Thomas’ book can become part of your standard library for your developers.

I’m checked out now, and in the closing session which is an open research panel with four Gartner panelists. They’re throwing up a statement and then debating it. The first prediction is “Through 2012, 40% of EA programs will be stopped due to poor execution.” The audience seemed to be in favor of the statement, although I wasn’t. Some of the audience comments had to do with lack of funding, lack of support, confusion with the value proposition for EA. I think it’s likely that 40% of the EA programs may change in how the company is attacking the problem (in fact, probably even more than that), but I’d be surprised if the program was abolished altogether.

The next statement is “By 2010, 70% of EA teams will be forced to spend as much time on information architecture as they currently spend on technical architecture.” About 70% of the audience agreed with this statement. I differ slightly. I definitely think the emphasis on information architecture will increase, but I also think some of the technical architecture may decrease. So, I would say that information architecture will probably receive equal treatment to technical architecture, but probably not as much as what technical architecture receives today. Interestingly, Nick Gall asked how many of us expect that Business Process Architecture will increase, more so than Information Architecture, in the next few years, and about 70% of us (myself included) agreed.

The final statement is “By 2010, the primary focus of technology architecture will shift from defining product standards to identifying and describing shared and repeatable technical services.” About 70% of the audience agreed with this. The key word that I disagree with on this one is the use of the term “technical services”. If your definition of this term includes “business services” exposed through technology, then I’d agree. If we’re talking about capabilities in the technical domains, like security, routing, etc., then I disagree. I think they are using the former definition, so I would agree with this one.

Time to head to the airport. I’d like to publicly thank the SOA Consortium and Pascal Winckel with Gartner for giving me the opportunity to be a speaker and for putting on two great summits. I especially enjoyed the EA Summit and hope to attend again.

In this session, Robert Handler is giving a talk entitled Communication, Persuasion, and Interpersonal Skills for EA. In a previous job, I worked with someone who was passionate about communications. He helped us create a communication plan around SOA and our competency center, and I really think it made a huge difference in our efforts, so I had a keen interest in this topic. I’ve previously blogged on some of the subjects in this presentation, including my Focus on the consumer entry.

Robert is spending a lot of time talking about Marketing and Sales, which is a great approach for this subject. For example, one task in marketing is identifying and segmenting it. Robert correctly points out the different segments for EA (senior leaders, business unit leaders, IT leaders, and IT groups) all want different things. Great point. I’ve met many technical people who want to create one thing and expect that everyone will see the inherent value in it when there hasn’t been any effort to tailor it or present it according to the differing needs.

He’s also spoken about creating the delivery system. Are you going to use a web portal? Wikis? Think about how your EA deliverables will be sent out to your markets. He’s also addressed branding and its importance.

On the sales side, he’s begun with a discussion on stakeholder analysis, and a detailed level at that. Again, it’s about understanding how to communicate and sell to the particular personalities and how they make decisions. Do they want a lot of detail? Do they want structure? Do they want to hear more about people and social issues, or do they want specific tasks? Again, there’s no one approach, it’s about matching the right approach to the right person.

He’s now talking about persuasion, and presenting techniques from the work of Dr. Robert Cialdini. He defines persuasion loosely as getting people to reply to your requests. The principles associated with persuasion include:

• Contrast principle: You can change the way someone experiences something by giving them a contrasting experience first.
• Principle of reciprocation: people feel obligated to give back somethign similar to what was given to them.
• Principle of scarcity: People want what they can’t have.
• Principle of authority/credibility: People defer decisions to experts, legitimate or otherwise.
• Principle of trust: Admit a flaw or weakness to show you are trustworthy.
• Principle of consistency: People want consistency and to be viewed as consistent.
• Principle of liking: People like those who like them, pleasant associations is the same as liking, people say yes to those who they believe are cooperating.

Message: keep these principles in mind as you sell EA. For example, he told us about a group that had little badges with LED lights that were given to projects that worked well with EA. The EA team was very stingy with them, however, adhering to the principle of scarcity. The result was that teams worked that much harder to be compliant, because they wanted these $2 badges that they could have ordered from Oriental Trading Company.

I’ve been really impressed with both of Robert’s sessions that I’ve attended. I’ve have to look into more of his research and recommend that other Gartner clients out there do so as well.

In this session, Robert Handler (of Gartner) is talking about the relationship between Enterprise Architecture and Project Portfolio Management (PPM). First off, there is clear overlap between the two efforts, provided that your PPM efforts are involved with the actual project definition and approval efforts, and not simply involved after project are approved and underway. Both efforts have the common desire to define projects that are intended to progress the company from a current state to a future state, although the criteria involved in project selection probably varies between the two.

On the PPM side, the biggest challenge is that this often isn’t happening. The survey quoted in the slides showed that the bulk of the time in PPM is spent mediating discussions on project priority, and just over 50% of the projects are even under the purview of the PPM effort. On the EA side, the slide states that most efforts are “mired in the creation of technical standards,” operating too much in a reactionary mode to current projects, and have very little effort on gap analysis. So, the end result is that neither effort is necessarily meeting their objectives, especially in the areas where they overlap, and neither effort is communicating well with the other.

He’s now showing an anchor model, and demonstrating how projects can be mapped onto the anchor model to show areas of concern and overlaps. I mentioned this anchor model in my blog entry on the Beginner’s Guide to Business Architecture session, and it’s jumping out again. This is definitely something that I need to get more information on, and hopefully start leveraging. He also presented a common requirements matrix and scoring approach which can assist in prioritization. The one challenge I see with this latter approach is that the projects all have to come along at the same time, which isn’t always the case. We’ll see if he gets to my question on this subject that I just submitted. (Note: he did, and pointed out that it doesn’t assume that everything comes in the same time, but that you do need to be willing to make adjustments to in-flight projects such as removing resources, altering scope, etc.)

Back to EA side of things, he’s advocating the use of patterns, principles, models, and standards as part of the architectural guidance that projects use. No arguments from me here. His slide also states that resource utilization in one organization went from 67% to over 80% when these are used effectively.

His closing recommendations are pretty straightforward. First, EA needs to be coordinated with PPM activities. Someone needs to take the first step to establish some synergies. Second, use coarse-grained EA deliverables for better project selection criteria. Third, use fine-grained EA deliverables on projects as gating factors. Fourth, capture some baselines and measure overall improvements, such as how long the design phase takes, productivity, etc. Finally, evolve maturity and effectiveness from where you are toward the ideal.

Overall, this was a very good session. It could have been a bit more prescriptive, but in terms of clearly showing the relationship between PPM and EA, it hit the mark.

In this talk, Richard Buchanan spoke for a long time on the tools that the business uses for strategic planning. Now, he’s talking about what EA’s need to do, because as he says, “EA is about strategic planning.” Tools he recommends includes product/service lifecycle management. Specifically, we need to model the definitive list of products or services the organization provides. This sounds a lot like Application Portfolio Management, and I would agree that not having that portfolio of IT “stuff” makes strategic planning very difficult. Another tools that he recommends is competitor analysis, which covers who the competitors are and how the organization competes with them. The next one is portfolio analysis, which is analogous to the Project Portfolio Management discussed in many of the AADI sessions. What are the major initiatives the organization is engaged in? Are there mergers and acquisitions in the pipeline?

The main takeaway from this for me is that a huge component of EA is analysis. I’ve always felt this, but given that many EA’s have grown out of the developer ranks and not the analyst ranks, myself included, we sometimes need to give ourselves a kick in the pants to do some of this work, rather than staying in our comfort zone of technology architecture and design.

While I didn’t attend the later session on it, in the opening keynote of the AADI Summit on Monday, the term “Context-Oriented Architecture” was mentioned. A colleague (thanks Craig!) caught me in the hall and asked me what my thoughts were on it, and as usual, my brain starting noodling away and the end result was me leaving the conversation saying, “you’ll see a blog entry on this very soon!”

I’ve brought up the slides from the Gartner session on it, and they estimate that sometime in the 2010’s, we will enter the “Era of Context” where important factors are presence, mobility, web 2.0 concepts, and social computing. The slides contain a new long acronym, WYNIWYG (Winnie Wig?), which stands for “What You Need is What You Get.” While it seems that the Gartner slides emphasize the importance that mobility will have in this paradigm, I’d like to bring it back into the enterprise context. While mobility is very important, there is still a huge need for WYNIWYG concepts in the desktop context. There will be no shortage of workers who still commute to the office building each day with the computer in their cube or their desktop being their primary point of interaction with the technology systems.

I think the WYNIWYG acronym captures the goal: what you need is what you get. The notion of context, however, implies that what you need changes frequently within a given day. Keith Harrison-Broninski, in his book Human Interactions, discusses how a lot of what we do is driven by the role we are playing at that point in time. If we take on multiple roles during the course of our day, shouldn’t we have context-sensitive interfaces that reflect this? If you’re asking the question, “Isn’t this the same thing as the personalization wave that went in (and out?) with web portals?” I want to make a distinction. Context-sensitivity has to be about productivity gains, not necessarily about user satisfaction gains. Allowing a user to put a “skin” on something or other look and feel tweaks may increase their overall level of satisfaction, but it may not make them any more productivity (I’m not implying that look and feel was the only thing that the personalization wave was about, but there was certainly a lot of it). As a better example of context-sensitivity, I point to the notion of Virtual Desktops. This has been around since the days of X Windows, with the most recent incarnation of it being Apple’s Spaces technology within Leopard. With this approach, I can put certain windows on “Virtual desktops” rather than have all of them clutter up a single desktop. With a keystroke, I can switch between them. So, a typical developer may have one “desktop” that has Eclipse open and maximized, and another “desktop” that has Outlook or your favorite mail client of choice, etc. Putting them all in one creates clutter, and the potential for interruptions and productivity losses when I need to shift (i.e. context-shift) from coding to responding to email.

Taking this beyond the developer, I bring in the advent of BPM and Workflow technologies. I’ve blogged previously on how I think this will create a need for very lightweight, specific-purpose user interfaces. Going a step further, these entry points should all be context-sensitivie. I’m doing this particular task, because I’m currently playing this role. Therefore, somehow, I need to have an association between a task and a role, and the task manager on my desktop needs to be able to interact with the user interaction container (not any one specific user interface, but rather a collection of interfaces) in a context-sensitive manner to present what I need. In our discussion, he brought up an example of an employee directory. An employee directory itself probably doesn’t need to be context aware. What does need to be context-aware is the presence or lack thereof of the employee directory depending on the role I’m currently playing. Therefore, it’s the UI container that must be context-sensitive.

All in all, this was a very interesting discussion. In looking at the Gartner slides, I definitely agree that this is a 2010+ sort of thing, but if you’re in a position to jump out (way) ahead of the curve, there’s probably some good productivity gains waiting to be had. I recommend getting pretty comfortable with your utilization of BPM technology first, and then moving on to this “era of context.”

I’m now in the Beginner’s Guide to Business Architecture session from Philip Allega. So far so good. He’s got a slide up right now showing an Anchor Model which presents a view that aligns nicely with my mental model of a diagram that shows the horizontal and vertical domains of the business. It’s nice to see something more formal than my own thoughts, and is exactly what I’m hoping to learn in this session.

The next components of a business architecture being discussed are principles and business domains. Interestingly, in doing technology architecture, I’ve worked with principles (technology-based, such as open-source vs. closed source, best of breed versus best fit, etc.) and technology domains. There’s really no difference in approach other than we’re now dealing with business principles (he gave the example of “No supplies will gain more than 5% of internal market share”) and business domains.

He’s now discussing roles that may be found in the BP & BA activities. There seems to be a strong correlation between BPI (Business Process Improvement) initiatives and Business Architecture. While he hasn’t come out and said that they are one and the same, it does make sense. If Business Architecture isn’t a once-and-done deal, then it makes sense that BPI is really just the continuous evolution of the Business Architecture.

Well that was fun! First off, kudos to Dr. Richard Soley from the SOA Consortium and Nick Gall from Gartner for getting us together and for doing an excellent job of moderating our panel. I really enjoyed the conversation and the answers from my fellow panelists, Bill Conroy, Global EA Executive for Bank of America, and Sam Vetto, Enterprise Architect for The Hartford Insurance Company. We covered a whole range of topics including governance, relationship between BPM and SOA, the relationship between information architecture and SOA, competency centers, funding SOA, and of course, the role of Enterprise Architecture in all of it. The topic of metrics came up frequently, just as with my previous panel. We certainly all agreed that EA has a role in all of this.

I’ve offered to address some of the questions that we didn’t get to in this blog, hopefully I’ll be able to coordinate with Gartner and make it happen. While you’ll only get my answer, one is better than none. If you attended the session, and have now found your way to my blog, please feel free to email me at todd at biske dot com or submit your questions via comments, and I’ll be happy to offer my thoughts. Also, I believe that this session will be available as a podcast in the future, so keep an eye out for it. I’ll be sure to link to it from here.

I’m now listening to Anne Lapkin discuss the strategy-driven enterprise. She first provided an example of an organization where there was in-fighting going on over who “owned” strategy between the portfolio management organization and the enterprise architecture organization. Both groups were trying to do the right thing, but there was a lot of wasted activity to mediate between these two organizations. The problem was that there was not one unified way of looking at the future state. She is advocating expressing the goals, principles, and relationships of a business, what she terms the Unified Enterprise Context, in a way that everyone will agree on. Interestingly, she tackled the question where an organizational has a collection of independent operating units by pointing out that in order to have a Unified Enterprise Context, you need to have a Unified Enterprise. That question was more indicative of a federated enterprise. If your enterprise is federated, each federated group should have its own Unified Enterprise Context, but there really isn’t one overarching context. Interestingly, I think this ties directly into Nick Gall’s keynote. The federated enterprise has a very small waistline, or area of commonality and generality, across their groups. Resist the urge the grow that waistline, and operate according to the federated model that the company has chosen.

The EA Summit has begun and Nick Gall is giving the opening keynote. He’s discussing a “middle-out” architecture style that “enables decentralized change through … minimal constraints.” He’s working hard to not digress into a REST discussion. 🙂 The visual metaphor is an hourglass, where there’s a small set of constraints in the middle that enables things to work, and things that grow outward in both directions. In the upward direction, it’s about the business. Many businesses can all be made to fit within these small constraints. Going down it is about the technology. Once again, there’s a multitude of technologies that can be made to fit those constraints. Many web servers all support the core web protocols.

Beyond the natural ties back to a REST approach, there’s a lot of truth to this metaphor. Both the business and the technology can be viewed as a hierarchical set of constraints. There are a small set of high level constraints that control everything that goes on underneath them. Architecture begins with these, and they are broadly applicable. Put too many of these things in the middle and, as Nick puts it, your waistline grows. If your waistline grows, things get more bloated, and you need more and management, process, etc. to ensure the adoption of these constraints and all of the exceptions associated with them. Doing income taxes comes to mind, for me. How many of the questions on my tax form are applicable to me? Having to go through the process of them makes things more complicated. Many things on the tax forms are so complicated that it’s difficult for an individual to know whether they even apply or not. At the opposite extreme, the narrowest of waistlines would be a standard flat tax. No exceptions, no complexity, just take 17% (or some other appropriate number) and give it to the government. Is there a need to distribute that tax to the local, regional, and federal agencies? Yes, but does that complexity need to be exposed to everyone in the middle? No, it doesn’t. Move it up/down in the hourglass to the areas that care about it, but don’t expose it generally to everyone.

If nothing else, Nick has certainly managed to get me noodling on this whole “narrow waistline” and hourglass approach. It’s a very interesting concept. The immediate concern that I have is that there’s a lot of changes that go on within the sands of the hourglass, and there’s a tendency for things to push toward the middle. To make this work, I think we’ll need appropriate guidance on how to maintain our perfect hourglass shape over time. I suggest using analogies of eating healthy and exercising frequently.