Todd Biske: Outside the Box

Archive for the ‘Gartner’ Category

According to ZDNet’s Joe McKendrick’s coverage of the recent Gartner Application Architecture, Development, and Integration summit, SOA governance and siloed thinking is top of mind.

If this really is the case, how do we make our governance efforts more effective? The more I think about this, the more I come back to a recent post of mine from earlier this year: “Want Successful Enterprise Architecture? Define ‘Enterprise’ First.” I’m convinced that this is a critical step for any effort that tries to go beyond a project-level scope, SOA initiatives included. If you don’t provide a structure that says what things will be implemented and managed at an enterprise level, versus a domain level or project/team level, anything with the term “enterprise” will be a struggle.

Too often, the approach to governance is concerned with establishing oversight, not establishing outcomes that are rooted in an agreed upon definition of what will be managed at an enterprise level, a domain level, and at the project level. Does it really help to set a standard that a particular coding library must be used when there is no central team that manages the library, no centralized support team, and no stated strategy for developer portability across projects? No, it just gets people up in arms and accusations of EA or the governance team being an ivory tower that sets arbitrary standards.

In my book, I defined governance as the combination of people, policies, and processes that are put in place to ensure the organization achieves one or more desired behaviors and outcomes. It’s not there to simply have a check mark to that says, “I went through a review.” In the absence of clear desired behaviors and outcomes, that’s what you will have. There is no reason to have an enterprise architecture team review a project if there are no things that are managed (or desired to be managed) at an enterprise level. You need to have some idea of what those things are up front, along with a mechanism for quickly making decisions on new candidates for enterprise items. The project team must know that this analysis will be done, and that it is a necessary part of achieving the company’s strategic goals, which they should be well aware of. Lack of communication of these goals can be just as detrimental and is often a symptom of lack of agreement on enterprise goals or inadequately specified goals: “Sure, we need to cut our IT costs by sharing more systems. I’m all for it as long as they’re not mine.” Someone needs to define exactly what the target areas are.

To be successful, we must define the desired outcome first. We must clearly establish the list of things that must be managed at an enterprise level, a divisional level, or left to the discretion of individual projects/teams. In fact, it’s even more fundamental than this. We can’t even know what success is without doing this step. There were no shortage of companies in the past that stated they were adopting SOA, my question to them would be, “How do you know when you’ve been successful?” Simply having a bunch of services doesn’t mean you’ve adopted SOA, it has to be the right services. Too often, enterprise architecture teams are positioned for failure because this fundamental step has not happened. Before you task your enterprise architecture team with reviewing all projects, make sure you’ve defined what enterprise is. If you haven’t, task your enterprise architecture team with doing the analysis of what’s out there and coming up with some recommendations. Then, your governance program will actually have a desired outcome to use in their reviews.

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.

I just posted a response to a question about the iPad in an enterprise setting over in an eBizQ forum and decided that I wanted to expand on it here in a blog post.

Much of the discussion about the iPad is still focusing on a feature by feature comparison to a netbook or a laptop. The discussion can not get out of the 20 year old world of keyboards, mice, and the windows and desktop metaphors. To properly think about what the iPad can do, you need to drop all of this context and think about things in new ways. In my previous post on the iPad, I emphasized this point, stating that the iPad is really about taking a new form of interaction (touch, with completely customizable interface) and putting it on a new form factor. In answering the eBizQ question, I realized that it goes beyond that. The key second factor is context awareness.

Back in 2007, I attended the Gartner Application Architecture, Development, and Integration Summit and the concept of “Context-Oriented Architecture” was introduced. In my blog post from the summit, I stated that:

[Gartner] estimates 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.

In that same post, I went on to state that this notion of context awareness will create a need for very lightweight, specific-purpose user interfaces. While at the time, I was leaning toward the use of Dashboard widgets or Vista sidebar items, but guess what has taken over that category? iPhone and iPod Touch apps. Now, we have the potential for a device with a larger form factor that can present a touch-based interface, completely tailored to the task at hand. This is another reason why I don’t see multi-tasking as a big deal. The target for this audience isn’t multi-tasking, it’s for these efficient, single-purpose interfaces. Imagine going into a conference room where your iPad is able to determine your meeting room through sensors in the building, where it knows what meeting you’re in and who else is in the room through calendar integration, it knows the subject of the meeting, and can now present you with a purpose-driven interface for that particular meeting. Our use of information can be made much more efficient. How many times have you been in a meeting only to wind up wasting time navigating around through your files, email, the company portal, etc. trying to find the right information. What if you had an app that organized it all and through context awareness, presented what you needed? The same certainly holds true for other activities in the enterprise beyond meetings. As we have more use of BPM and Workflow technologies, it is certainly possible that context awareness through location, time, presence of others, and more can allow more appropriate and efficient interfaces for task display and execution, in addition to providing context back into the system to aid in continuous improvement.

This isn’t going to happen overnight, but I am very excited to see whether Gartner’s prediction of the 2010’s being the “era of context” comes true. I think it will, and it will be great to look back from 2020 and see just how much things have changed.

A Gartner press release resulted in some very good posts in the blogosphere related to the future of enterprise architecture. Gartner coined the term ’emergent architecture’ and encouraged companies to adopt it. For the record, I’ve decided that I really don’t like that term, and I don’t think Gartner did a very good job of defining it. They provided a list of seven differentiators from “the traditional approach to EA” but, as Mike Rollings of Burton Group pointed out in his post, most of these things are items that many practicing enterprise architects already did and knew. Do we really need a term for what many of us are already doing?

The post that I really liked came from Dion Hinchliffe at ZDNet. The reason for this is the image that he used in the post, shown here:

While I still don’t like the use of the term emergent architecture and “non-deterministic outcomes”, the picture tries to draw a picture of the forces the come into play in producing solutions.

So what is the role of EA in the future? First, the thing that doesn’t change is the role of EA in providing context. This context is an influencer on the activities that occur in the enterprise. Dion’s drawing attempts to touch on this, but goes at the scope of influence in terms of who can be influenced, rather than the information used to influence. It’s the role of the enterprise architect to bring additional context from outside of the normal scope of the effort to the solution discussion. Influence is not about centralized decision making, so as Mike Rollings called out, most EA’s have never been a centralized decision maker for all things architecture and never will be. We’re simply another party providing influence. Sometimes we have stronger methods, sometimes someone else does. In my book, SOA Governance, I emphasized policy creation first, then policy communication. If the policies are known, any decision maker can apply those policies consistently.

What Dion’s diagram doesn’t capture, is the changing way in which solutions get done. He still has the “projects” box up there. There are many of us that feel this project-based culture is part of the problem. If we take a more product-based or even service-based view of our solutions, those solutions will need to be nurtured and evolve over time, rather than stood up, ignored, and then uprooted with significant effort. This notion, as others have called out, including Neil Macehiter and Neil Ward-Dutton in their book The Technology Garden and practicing enterprise architect James McGovern in his blog, is that of gardening. Do you simply let anything emerge in your garden? No. You plant specific things, remove the weeds, remove weak plants, change some things from year to year, etc. If you don’t plan the garden properly, weeds can choke the life out of other plants, or there can be conflicts within the garden itself, with one type of plant consuming higher amounts of resources, causing others to wither and die.

Coming back to the role of EA as influencer though, the thing we must realize is that the dynamics around us are changing, and as a result, it may change who and how we influence. More and more things are bought rather than built. The level of consumer technology has changed the bar in terms of what individuals can do and expect. If we don’t change our ways along with it, our ability to influence will be diminished. This doesn’t mean things are now emergent. There have always been things that have been emergent, and a healthy company always has some efforts that fall into the category of throw it against the wall and see if it sticks. What’s changed is the pace at which we can do it. We need to incorporate this into the way we execute. I believe the trend toward business architecture is a clear sign of EA trying to do this. We must remember, however, that the artifacts and techniques used to provide context to developers and engineers may not work with the business. We need to speak the business language, not try to get them to understand ours.

I had a brief conversation with Nick Gall (Twitter: ironick) of Gartner on Twitter regarding designing for change. Back in the early days of SOA, I’m pretty sure that I first heard the phrase, “we need to build things to change” from a Gartner analyst, although I don’t recall which one. Since that time, there’s been a lot of discussion on the subject of designing/building for change, usually tied to a discussion on REST versus WS-*. Yesterday, I stepped back from the debate and thought, “Can we ever design for change, and is that really the right problem?”

As I told Nick, technology and design choices can certain constrain the flexibility that you have. Think about the office building that many of us work in. There was a time when they weren’t big farms of cubicle and they actually had real walls and doors. Did this design work? Yes. Was it flexible enough to meet the needs of an expanding work force? No. I couldn’t easily and quickly create new conference rooms, change the size of spaces, etc. Did it meet all possible changes the company would go through? No. Did the planners ever think that every cubicle would consume the amount of electricity they do today? What about wiring for the Internet? Sometimes those buildings need to be renovated or even bulldozed. The same thing is true on the technology side. We made some design decisions that worked and were flexibility, yet not flexible enough for the change that could not have been easily predicted in most companies, such as the advent of the internet.

Maybe I’m getting wiser as I go through more of these technology changes, but for me, the fundamental problem is not the technology selection. Yes, poor design and technology selection can be limiting, but I think the bigger problem is that we have poor processes for determining what changes are definitely coming, what changes might be coming, and how and when to incorporate those changes into what IT does, despite the available predictions from the various analysts. Instead, we have a reactive, project-driven approach without any sort of portfolio planning and management expertise. To this, I’m reminded of a thought I had while sitting in a Gartner talk on application and project portfolio management a year or two ago. If I’m sitting in a similar session on service portfolio management 5 years from now, we’ve missed the boat and we still don’t get it. Develop a process for change, and it well help you make good, timely design choices. The process for change involves sound portfolio management and rationalization processes.

Presenter: Scott Bittler, Gartner

Another presentation from Scott, this time over breakfast. The bulk of this talk was focused on the importance of what he termed as “Next State Architecture.” If we have the future state and current state architectures documented, the challenge that exists is if we can’t achieve the future state architecture in one step. If that’s the case, then there’s a gap in the prescriptive guidance needed for project teams. If they know they can’t get to the future state, and don’t have guidance on how they should move from current state, they’re likely to stick with what they know. Good advice.

There were some specific nuggets outside of this core topic that I also wanted to call out. First, he said that the most important EA deliverable is principles, because it’s those principles that lead to consistent decision making. The talk wasn’t focused on this, so he didn’t go into depth, but some examples of these principles would be good. I definitely see the importance in these and agree with his statement. I’ve been in many situations with two (or more) compelling options where we seem to be at a stalemate. The principles need to assist in getting decisions made.

Second, I liked the fact that he said that EA’s role is to provide prescriptive guidance so that appropriate choices are made on projects and programs. This emphasizes the point that I was hoping would be made in his governance talk yesterday. Provide the policies, and anyone can make the right decisions.

Finally, the last comment he made was that with the advent of EA-focused web sites, etc., any team that claims ignorance when confronted with non-compliance (“I didn’t know I was supposed to do that”) is unacceptable in this day. Here, I disagree. I make extensive use of RSS feeds in my work so that I get information pushed to me, but I know many of my colleagues do not. A web site is still a pull-model, and there’s very few people that I know of that have the discipline to regularly check common web sites. EA has to be accountable for the communication effort and ensuring that it gets pushed out to the people who need it. Putting it on a web site isn’t enough. So, this one I disagree with. I think if EA is serious about achieving compliance, then they should be serious about pushing the information out. Create a formal communication plan and execute it.

Presenter: Scott Bittler, Gartner

This presentation got me on my soap box. This talk took the traditional approach to governance, framing it around decision rights. In my opinion, this is too narrow of a scope and leads to the typical review board approach that contributes to the negative connotation most project staff have around governance. A focus on decision rights always jumps to some kind of an exception process, or better stated, a situation where there is a project that is not compliant with the architecture. The problem I have with this view is that these decisions assume that the project was knowingly out of compliance. More often than not, I don’t think that’s the case. I think the project team isn’t aware of what “in compliance” is, makes decisions based upon their knowledge and context, and only when (and if) someone else who has some other context comes into the picture, does a discussion around “decision rights” even enter the mix. When that happens, it’s usually too late in the project, and the schedule wins. What’s the real source of the problem here? It’s not a problem with decision rights, it’s a problem with not providing the people making the decisions the knowledge they need to do it right. What’s even worse in that if we didn’t even find out about the non-compliance, the focus is misplaced on inserting a checkpoint/review instead of actually getting the project team to make the right decision to begin with.

Put another way, how fast would you drive on a road that has no speed limit signs posted? If everyone was speeding, is the right answer to put police officers out there every mile, or is the right answer to post speed limit signs. Unfortunately, with projects, we’re doing the former. We stick more police out in the form of big review boards, but we still haven’t bothered to give the teams the information they need to do things right.

Instead of focusing on who has authority, focus on what the policies are that state what the “right” thing to do is, and enable the people that are must make the decisions to make them properly, rather than taking away their ability to make decisions by requiring them to guess which decisions must be escalated up the ladder to the person who is deemed the authority. The person who is the authority shouldn’t be making decisions, they should be making policies and enabling the decision makers.

The session is now over, and I want to point out that his recommendations slide did have a bullet point encouraging lots of proactive communication on the architecture. I also want to add that there was good content in the presentation, especially the brief discussion on federated governance across business units near the end, I just wish he had emphasized his recommendation on proactive communication (and introduced the concept of policy as part of that) in the earlier slides instead of so much focus on review boards and waivers. I caught him after the presentation and told him about my book, hopefully we can continue the conversation. He’s not on Gartner’s blogroll yet, so I’ll have to hope for some offline communication on the topic.

In this session, Bernadette Rasmussen, Chief Enterprise Architect at Health Care Service Corporation, gave a case study discussing their efforts to establish a future-state architecture. The highlight of this session for me was the fact that a deliverable of their future state architecture was a formal communication plan, and then the actual communication activities articulated in that plan. This included large presentations for lots of people, DVDs containing an overview, development of on-line training, formal communication to senior IT leadership (who in turn had them communicate it senior leadership outside of IT), and more. I’ve had the opportunity to work on one enterprise-level effort with someone who was passionate about communication and had us develop a similar plan, and I think it was a huge contributor to the success of the effort. Developing the artifacts is one thing, but if people don’t know they exist, they won’t get used.

Presenter: Al Newman, Director of Architecture Services at Allstate Insurance Company

Al discussed Allstate’s journey on the path to establishing a business architecture practice at Allstate.

He walked us through an eight step process:

1. Define business architecture
2. Secure executive sponsorship
3. Develop a framework
4. Secure an initial engagement
5. Build an engagement team
6. Creating a competency center
7. Build out infrastructure
8. Formalize the operating model

Two highlights that I wanted to call out. First, he’s emphasized the need for an engagement model. I’ve seen too many teams, whether formally on the org chart or not, that don’t have an idea on how either the team members or the artifacts that they may create will be utilized within project efforts. In the IT organizations I’ve seen, the work gets done in projects, period. Architecture teams that don’t have people formally allocated to projects need to figure out how their artifacts and/or staff will be utilized in those projects.

Second, he emphasized the need for business architecture in making solid project decisions. I couldn’t agree more, and have a chapter discussing this in an SOA context in my book. In the context of SOA, one question that gets asked is “How do I build the right services?” Asking this question after a project has been initiated is already problematic as the project establishes scope boundaries, and changing those requires more effort than it would have if those discussions were had during the project definition process.

I will be at the Gartner EA Summit in Vegas on Thursday the 11th and Friday the 12th, including being a panelist on EA and SOA on Friday morning. Introduce yourself to me there and perhaps you will get a discount code for my book. Offer open to attendees only.

The idea of context-driven architecture, as coined by Gartner, has been bouncing around my head since the Gartner AADI and EA Summits I attended in June. It’s a catch phrase that basically means that we need to design our applications to take into account as much as possible of the context in which it is executed. It’s especially true for mobile applications, where the whole notion of location awareness has people thinking about new and exciting things, albeit more so in the consumer space than in the enterprise. While I expect to have a number of additional posts on this subject in the future, a recent discussion with a colleague on Data Warehousing inspired this post.

In the data warehousing/business intelligence space, there is certainly a maturity curve to how well an enterprise can leverage the technology. In its most basic form, there’s a clear separation between the OLTP world and the DW/BI world. OLTP handles the day to day stuff, some ETL (extract-transform-load) job gets run to put it into DW, and then some user leverages the BI tools to do analytics or run reports. These tools enable the user to look for trends, clusters, or other data mining type of activities. Now, think of a company like Amazon. Amazon incorporates these trends and clusters into the recommendations it makes for you when you log in. Does Amazon’s back-end run some sophisticated analytics process every time I log in? I’d be surprised if it did, since performing that data mining is an expensive operation. I’m guessing (and it is a guess, I have no idea on the technical details inside of Amazon) that the analytics go on in the background somewhere. If this is the case, then this means that the incorporation of the results of the analytical processing (not the actual analytics itself) is coded into the OLTP application that we use when we log in.

So what does this have to do with context-driven architecture? Well, what I realized is that it all comes down to figuring out what’s important. We can run a BI tool on the DW, get a visual representation, and quickly spot clusters, etc. Humans are good at that. How do you tell a machine to do that, though? We can’t just expect to hook our customer facing applications up to a DW and expect magic to happen. Odds are, we need to take the first step of having a real person look at the information, decide what is relevant or not with the assistance of analytical tools. Only then can we set up some regular jobs to execute those analytics and store the results somewhere that is easily accessible by an OLTP application. In other words, we need to do analysis to figure out what the “right” context is. Once we’ve established the correlation, now we can begin to leverage that context in a way that’s suitable for the typical OLTP application.

So, if you’re like me, and just starting to noodle on this notion, I’d first take a look at your maturity around your data warehousing and business intelligence tools. If you’re relatively mature in that space, that I expect that a leap toward context-driven applications probably won’t be a big stretch for you. If you’re relatively immature, you may want to focus on building that maturity up, rather than jumping into context-driven applications before you’re ready.

This is my last post from the summits (actually, I’m already at the airport). This morning, I participated in a panel discussion on EA and SOA as part of the EA Summit with Marty Colburn, Executive VP and CTO for FINRA; Maja Tibbling, Lead Enterprise Architect for Con-way; and John Williams, Enterprise Architect from QBE Regional Insurance. The panel was jointly moderated by Dr. Richard Soley of the OMG and SOA Consortium and Bruce Robertson of Gartner. It was another excellent session in my opinion. We all brought different perspectives on how we had approached SOA and EA, yet there was some apparent commonalities. Number one was the universal answer to what the most challenging things was with SOA adoption: culture change.

There were a large number of questions submitted, and unfortunately, we didn’t get to all of them. The conference director, Pascal Winckel (who did a great job by the way), has said he will try to get these posted onto the conference blog, and I will do my best to either answer them here on my blog or via comments on the Gartner blog. As always, if you have questions, feel free to send them to me here. I’d be happy to address them, and will keep all of the anonymous, if so desired.

I just attended a case study at the summit. The presenter requested that their slides not be made available, so I’m being cautious about what I write. There was one thing I wanted to call out, which was that the case study described some application portfolio analysis efforts and mapping of capabilities to the portfolio. I’ve recently been giving a lot of thought to the analysis side of SOA, and how an organization can enable themselves to build the “right” services. One of the techniques I thought made sense was exactly what he just described with the mapping of capabilities. Easier said than done, though. I think most of us would agree that performing analysis outside of the context of a project could provide great benefits, but the problem is that most organizations have all their resources focused on running the business and executing projects. This is a very tactical view, and the usual objection is that as a result, they can’t afford to do a more strategic analysis. It was nice to hear from an organization that could.

Presenters: Anne Lapkin and Colleen Young

One thing all of the presenters in the EA Summit are very good at doing is using consistent diagrams across all of their presentations. This is at least the third presentation where I’ve seen this flow diagram showing linkage between business goals and strategy, and business planning and execution. Unfortunately, Anne points out that the linkage is where things typically break down.

Colleen is now discussing strategic integration, which begins with an actionable articulation of business strategy, goals and objectives. From there, she recommends a standardized, integrated, results-based management methodology. As a result, she claims that we will see exponentially greater benefits from enterprise capabilities and investments.

Anne is speaking again and emphasizing that we need a unified contextual view. This consists of a goal, which is one level deeper than the “grow revenues by XY%” which includes a future end state with a timeline and measurable targets, principles that establish the desired behavior and core values, and relationships.

Colleen now has a great slide up called, “The Implication of ‘Implications’.” The tag line says it all- “Unclear implications lead to inconsistent assumptions and independent response strategies that inevitably clash.” Implications that must be investigated include financial implications, business process implications, architecture implications, cultural change implications, and more. All parties involved must understand and agree on these implications.

A statement Colleen just made that resonates with my current thinking is, “Based upon these implications, what do I need to change?” All too often, we don’t stop to think about what the “change” really is. Work starts happening, but no one really has a clear idea of why we’re doing it, only an innate trust that the work is necessary and valuable. If the earlier planning activities have made these goals explicit, the execution should be smoother, and when bumps in the road are encountered, the principles are right there to guide the decision making process, rather than on relying on someone’s interpretation of an undocumented implication.

Once again, this was a good session. I know I’ve commented on a few sessions that they could have been a bit more pragmatic or actionable, this one definitely achieved that goal. I think the attendees will be able to leave with some concrete guidance that they can turn around and use in their organizations.

Presenter: Richard Buchanan

The first topic Richard is covering is the need for enterprise architects to master strategic thinking. His current slide is consistent with an earlier talk today, showing that enterprise strategy is at the intersection of three disciplines: Enterprise Strategy and Planning, Enterprise Architecture, and Enterprise Portfolio Management. He states that enterprise architecture must translate business vision and strategy into effective enterprise change. He’s discussing how a budget and the organization chart are not part of the business strategy, pointing out that a budget should be a downstream deliverable derived from the business strategy. Great point. His definition of strategy includes an organization’s environment, goals, objectives, major programs of action, and the resource allocation choices to execute them.

The next topic he is covering are the categories of tools and techniques that are used in developing a business strategy. These are not software tools, as the first one he’s showing is Porter’s 5 Forces Model (this is second time Michael Porter has been referenced at the Summit). He’s challenging us to go and find the people in our organization that are looking at these things. Good advice. There’s no doubt that if you want to do strategic planning, you need to be looking at these five forces, and there’s a good chance that someone at the company (probably outside of IT) is already doing this. The same thing holds true for the other categories of tools that he has went through.

The final point he’s covering is how to leverage these strategic tools within the EA process. To some extent this is motherhood and apple pie, but it’s very good advice, especially knowing that many EA’s have grown out of the world of application development and may still be very technology focused. As a result, it’s entirely possible that the EA team has never read the company’s annual report. It’s even more likely that EA hasn’t seen things like competitive analysis documents. If an EA doesn’t understand how a company competes, how can they make appropriate decisions? Speaking very broadly and citing Michael Raynor’s earlier presentation, do you know whether your company differentiates on cost or on products? Both of those can have significant impacts on how information technology is leveraged. A company that differentiates based on product excellence and customer service must have significantly better technology for understanding their customers than a company that simply tries to be the lowest cost provider in the marketplace.

My final thoughts: There’s not much to disagree with in this presentation. I think he paints a great picture of what many of us would like to be doing. The challenge I suspect that many attendees have is that our EA organizations, as a previous presenter put it, “are mired in the world of technology architecture.” Somehow, we need to find a seat at the strategic planning table so when we ask about some of these artifacts, everyone knows its importance versus stopping us in our tracks and asking, “Why do you need it?”

Presenter: William Clark

I’m looking forward to this talk, as it’s a new area for me. I don’t remember who told me this, but the key to getting something out of a conference is go to sessions where you have the opportunity to learn something, and you’re interested in the subject. That’s why I’m avoiding sessions on establishing enterprise technology architects. I’ve been doing that for the past 5 years, so the chances are far less that I’m going to learn something new than in a session like this one, where it’s an emerging space and I know it’s something that is going to be more and more important in my work in the next few years. The only downside is I’m now on my fourth day in Orlando which is starting to surpass my tolerance limit for sitting and listening to presentations.

He’s started out by showing that the thing missing from the digital experience today is “me.” By me, he implies the context of why we’re doing the things that we’re doing, such as “where am I,” “what have I done,” “who are you talking to,” etc. He points out the importance of user experience in the success and failures of projects, especially now in the mobile space.

Some challenges he calls out with incorporating context into our systems:

• Blending of personal contexts and business contexts. For example, just think of how your personal calendar(s) may overlap with your business calendar.
• Managing Technical Contexts: What device are you using, what network are you connecting from, etc. and what are the associated technical capabilities available at that point?
• Context timing: The context is always in a state of flux. Do I try to predict near-term changes to the context, do I try to capture the current context, or do I leverage the near-past context (or even longer) in what is shown?

It’s always a sign of a good presentation when they anticipate questions an audience might ask. I was just about to write down a question asking him if he thinks that a marketplace for context delivery will show up, and he started talking about exactly that. This is a really interesting space, because there’s historical context that can be captured and saved, and there’s an expense associated with that, so it makes sense that the information broker market that currently selling marketing lists, etc. will expand to become on-demand context providers with B2B style integrations.

All in all, I see this space with parallels to the early days of business intelligence. The early adopters are out there, trying to figure out what the most valuable areas of “context” are. Unlike BI, there are so many technology changes going on that are introducing new paradigms, like location aware context with cellphones, there’s even more uncertainty. I asked a question wondering how long it will be before some “safe” areas have been established for companies to begin leveraging this, but his answer was that there are many dimensions contributing to that tipping point, so it’s very hard to make any predictions.

This was a good presentation. I think he gave a good sampling of the different data points that go into context, some of the challenges associated with it, and the technical dynamics driving it. It’s safe to say that we’re not at the point where we should be recommending significant investments in this, but we are at the point where we should be doing some early research to determine where we can leverage context in our solutions and subsequently make sound investment decisions.