Todd Biske: Outside the Box

The presenter is Gary Doucet, the Chief Architect for the Government of Canada. His summary is that EA makes everything the business does better. EA needs to be ubiquitous, not owned by any single non-EA process. He emphasized that there are hidden architects all over the place, producing artifacts (artefacts, if you’re from Canada like him), that are the descriptions of the business today. EA’s role is to discover and align these efforts, not necessarily to own them all. Interesting talk.

I’m now in the keynote from Nick Carr, author of IT Doesn’t Matter and his latest book, The Big Switch. I haven’t read his book yet (I did get a copy when he offered to send free ones to the first 100 bloggers who responded), but from reading the reviews of others and comments around it, I knew that it was basically advocating a cloud computing approach to corporate IT. His presentation reaffirmed this. Nothing much to say beyond that, they’ve now transitioned to a discussion with him and Darryl Plummer and David Mitchell Smith. The first question from Darryl was on the moving of data into the cloud. Nick’s response was that company’s will do it when their competitors wind up “saving millions of dollars” by doing it. Darryl drilled more into the notion of what to do with the legacy “stuff” and Nick expects that for the foreseeable future, large companies will have a hybrid model, slowly moving things into the cloud. He feels that smaller and mid-size companies will be quicker to adopt. David then asked if 50 years out, the Google data center that Nick used in one slide will be seen as “the dinosaur” and replaced by a peer-to-peer model. Nick hesitated a bit and said that 50 years is hard to predict in technology, but then said he doesn’t see it. Personally, I agree with David, and I think Nick’s analogy to power grids shows it. We moved to centralized power generation, and now with the focus on being green, we now see individual home owners contributing back to the grid through solar panels on their roof, etc. It wouldn’t surprise me at all, as standards evolve, to see individuals contributing their compute resources back to the cloud, however, we’d need to have far, far better standards for doing so. I had a conversation with Mike Kavis about this at lunch, and we both agreed that the cost of moving is still too high. I can’t simply take the .ear file from my application server and stick it on a server in the cloud yet. We’ll get there, though, and that’s when it will become a more interesting discussion for the large enterprise.

Darryl just did an informal audience poll, asking the question, “How many of you think a significant part of your IT will leverage cloud computing in 2 years, 5 years, and 10 years?” Within 2 years, there were probably less than 20 people. At 10 years, probably about 30-40% of the room said yes. That’s probably realistic, especially not knowing the size of the companies that are represented here. If 30% of the people here represent SMB’s, it’s a no-brainer in my opinion in a 10 year timeframe. Ultimately, this was just a fun exercise to stimulate the discussion, much as how Darryl pinned Nick down to make a prediction on how many of us won’t have a job due to this “big switch” in 10 years. For the record, Nick said 60%, but then said the more safe statement, “IT headcounts will be at lower levels than they are now.”

Presenter: Betsy Burton

The presentation is starting out with a future vision statement. They believe that “by 2011, the majority of automated business processes at Global 1000 organizations will have evolved our thinking about processes with a shift from linear to nonlinear. Processes will have evolved to include a combination of formal workflow, information analysis, social networks, collaboration and ‘person-centric’ processes.”

She states that the goal of business architecture is to create the foundational artifacts for people to define the organization and enable change in the organization toward a future state. The interesting term in this statement for me is “organization.” Having roots in IT, we often want to talk about technology, and the application of technology, but when we bleed into organizational discussions, many architects think that it’s the job of management. Guess what? Organization can be an impediment or an enabler for being successful with technology so it is something that we need to think about. If it’s management’s responsibility, then invite them to the table and include them in the discussions so your efforts can be successful. As she just stated, “70% of what EA does is family counseling.” Don’t ignore the people!

She’s now moved on to the dimensions of business architecture. She includes people, financials, organization, and process. All of these are layered across the business functions of the organization. If we have these dimensions, we then need to develop requirements of business processes, the principles that guide people’s use of business processes, and the models of what the processes should look like in the current and end state. She now has a slide, and she’s showing an example of an anchor model and it’s importance to Enterprise Architecture. I’m really glad she called this out, because it aligns directly with my horizontal/vertical thinking I’ve mentioned before. I called this out back in the December EA Summit, and it’s nice to see that their thinking has continued to evolve. The anchor model is a representation of the business capabilities of the organization, and as the name suggests, it’s an anchor for other efforts like SOA and BPM.

There’s a ton of good information being presented here at a very fast pace, so I’m not going to keep trying to quote things. They’ve given a great walkthrough from the anchor model into some swim lane diagrams of processes, and have stated that this example is available online. If you’re a Gartner subscriber, and interested in this, I recommended looking for the “Bank XYZ” example artifacts that they have. As someone hoping to look more into business architecture in the future, I think this material is going to be very useful.

Her final recommendations in the standard Gartner powerpoint template are:

• Don’t do the business architecture in a vacuum.

• Focus on interdependent business and IT viewpoints, aligned in the solution architecture.
• Use a multidisciplinary team approach.
• Business architecture is much more than process optimization.

Presenter: Colleen Young

This is the opening keynote for the EA Summit. Colleen is telling us that we are the individuals that need to bring the message to the business that IT can contribute to growth, rather than simply being about back-end processes and support. Things that she says that are critical to success of EA:

1. EA’s must be bilingual- speaking the language of the business and the language of IT.
2. Architects must be political.
3. Architects must be influential. Architects need to be confident, with a firm grasp on the business’ needs.
4. Architects must deliver distinctive solutions. How do we do this? We need to evolve toward integrated IT and business strategic planning. Architecture needs to bridge the gap.

Overall, a good presentation.

I just finished my panel discussion with Mel Greer and Mike Kavis on measuring the value of SOA. I think we all had hoped that there would be more attendees, but hopefully those that chose to attend got something out of it. My main message was measure, measure, measure. I think it’s difficult to put a direct value on SOA adoption, that is, one where you can say the value was directly as a result of SOA efforts, but it’s not difficult to put a contributory value on SOA adoption. In other words, we need to measure the way IT is contributing to the success of the company as a whole, and as part of that, we can see some before and after measurements to see the impact of SOA and any other changes. The two things that I brought up in answering questions that I thought I’d share here are:

• Instrument your services now. Part of the problem with measuring things today is that we haven’t instrumented things in the past. These days, value is almost always expressed in relative terms, such as “relative to what we’re doing now.” If you’re not collecting metrics, you can’t say what “now” is, though. Once again, we’re at one of those unique opportunities where the door is open to do things differently. Put the instrumentation in now, before you have a portfolio of 100+ services that have no instrumentation.
• Measuring puts the spotlight on you, but will always enable you to answer questions better than before. A member of the audience asked the question, “What happens if your measurements show that you’re not achieving your goals?” This was a great question. Unfortunately, sometimes by the mere act of measuring things, people will immediately put the blame on you when things aren’t achieving the desired benefits, simply because you’re the one thing that can concretely demonstrate contribution (or lack thereof). My answer to this was two-fold. First, it was to try to make sure you have the backing metrics to allow proper root cause analysis. If you just focus on one metric, and nothing else, it makes root cause identification very difficult, and it puts the spotlight at the one area when you’re measuring. This puts strategic initiatives like SOA at risk, because people will think the whole thing is flawed, when in fact, the lack of results may have nothing at all to do with SOA adoption. Second, I talked about the appropriate spin to put on it, this being the political season in the US. When something doesn’t work out as planned, the way to spin the metrics is to show that we’re in a better spot to fix the problem because of the measurements than we would have been before.

The final thing I wanted to call out was a reference to a blog I posted yesterday at the request of Rob Eamon. Someone asked a question about how to get the stated goals from “the business” and the role of IT in contributing ways of measuring it. I called out that IT is part of the business, so there’s no reason that IT can’t contribute to the definition and appropriate ways to measure the business goals. Rather than viewing it as an “extraction” effort, it should be a joint effort with all members of the business, which includes IT.

If you attended the session, please feel free to post any comments or questions here. I hope it was valuable.

Presenter: Dr. Andrew Lippman from MIT’s Media Laboratory

Dr. Lippman came and talked to us about MIT Media Lab in a keynote this morning. He was an excellent speaker. Most of the talk was focused on how technology can contribute to the increasingly social nature of our society. While we increasingly have more and more personal technology, the usefulness of that technology will largely depend on its ability to focus on the “we” rather than on “me.” A great point that he made is that a company’s value is in its social network- the speed with which the values and ideas flow through the company. Again, the degree to which technology supports that is a key element. Excellent talk.

Presenter: Daniel Sholler

Dan is largely presenting results from some surveys that Gartner has done. Highlights:

1. Adoption is increasing, but so is number of organizations that are choosing to delay/do nothing
2. Nearly all organizations are at maturity level 1
3. Of the very few organizations that are above level 1, interest/usage in WOA/REST is increasing
4. More mature organizations are using services for B2B and multi-channel applications
5. Only 1/3 of organizations adopting SOA are using an ESB
6. Stage 2 maturity companies have nearly double the number of service consumers for the same number of services as Stage 1 maturity companies
7. “BPM is the ‘killer app’ for SOA”

My thoughts: Nothing really surprising here. I’m not at all surprised that we’re at a very early stage of maturity. The statement that the more mature organizations are pursuing B2B and multi-channel opportunities is an aberration, in my opinion. I think those are simply opportunities that some organizations have and other don’t, rather than being tied to the maturity of the organization. The bullet point that more mature organizations have twice the number of consumers was interesting to me. That one seems to make sense from a maturity standpoint. The BPM comment isn’t surprising at all, because I don’t think you can do a good job with BPM without having services.

Presenter: Andy Kyte

The title of this session is, “If You Had an Application Strategy, What Would It Look Like?” So far, I think I’m going to like it, because he’s emphasizing the need to manage the application lifecycle. That’s application lifecycle, not application development lifecycle. The application lifecycle ends when the last version of the application is removed from production. He’s emphasizing that an application is both an asset and a liability, with the liability being all of the people, technologies, and skills required to sustain it.

He’s now getting a ton of laughs by using a puppy/dog metaphor. He stated that we don’t buy a puppy, we buy a dog. It may be all cute and playful when we get it, but it will grow in a dog that sheds, eats, etc. Applications are the same way. Great quote just now: “Business cases are focused on putting applications in, and not on what to do after it. We are contributed to the problem by not addressing this.” He emphasizes that an application strategy should cover the next seven years, or half the expected remaining life of the application, whichever is the greater.

He’s now talking about stakeholder management and hitting on all the points I usually mention when talking about Service Lifecycle Management. The application is an asset, it must have an individual who is responsible for it, lifecycle decisions should be transparent, and all stakeholders (i.e. users of the application) must be identified and actively encouraged to play some role in the governance of the application.

The rest of the session is focusing in on the creation of the strategy document and making sure that it is a living, useful document. He’s emphasized that it is a plan, but also stressed the first law of planning: “No plan survives contact with the enemy.” It’s recognized that the plan is based on assumptions about the future. By documenting those assumptions, including leading indicators, leading contra-indicators, and expected timings, we can continually monitor and change the plan.

Overall, this is a very, very good session. What’s great about this is it is promoting a genuine change in thinking in the way that probably 90% of the companies here operate. Add a great speaker to the mix, and you’ve got a very good talk.

Frequent commenter Rob Eamon suggested a topic for me, hopefully he won’t mind me copying his email verbatim here:

One term that is starting to bug me more and more is “the business.” There is an implicit definition about this group and in IT circles that group is almost always referred to as “they.”

“That’s for ‘the business’ to decide.”
“We need to touch base with ‘the business’ on that.”

IMO, this tends to reinforce divide between groups.

So what exactly is “the business?” Why is IT typically assumed to be excluded from this group? Aren’t all groups in the company part of “the business?” Why do so many refer to “the business” as “internal customers?”

Smaller companies seem to embrace this seemingly arbitrary division much less so than do large companies.

I’m with you Rob. Many organizations have a separation between IT and everyone else, and even worse, it’s always IT referring to everyone else as “the business,” versus the non-IT staff treating IT as if it weren’t part of the company (although that happens too).

Part of the challenge is that IT works with nearly everyone outside of IT, and there isn’t a good term to describe them as a whole. Unfortunately, you hit the nail on the head. By referring to them as “the business,” there’s an implication that IT is not part of “the business.” It’s a shame that this is the case. I remember back in my days of focusing on usability where I had the opportunity to work on a cross-functional team with members of the Internet marketing group on an application. It improved things tremendously when we were able to work as a team, rather than as “the business” and IT. Unfortunately, this still tends to be the exception rather than the norm. So what should we do? Well, I don’t think we need another term to use. What we should be doing is getting off of our IT floors, and actually learning about the rest of the business. When we need to refer to a group outside of IT, refer to the group by their organizational name. If the application is for marketing, don’t call them “the business,” call them marketing. If it is for HR, call them HR.

One other question Rob asked was around the notion of “internal customers.” Like him, I don’t like the customer metaphor when talking about internal IT. The scary thing is, if IT had more of a customer service mentality, things would actually be better. The fact is, IT doesn’t have a good track record of customer service. We get away with lousy service because we’re part of the business. If we were an outsourcing company, we probably would have been shown the door a long time ago. IT should be better, not worse, than an outsourcing group. The only way to achieve this, however, is to get everyone in the company operating as a team, and continuing to emphasize that team mentality. It’s far too easy to get away with poor behavior with those you know, because the ramifications are usually less. As a testament to this, I think of my kids. First off, they’re great kids. But, if you’re a parent, I’m sure you can relate to this. My kids typically have excellent manners when dealing with the parents of their friends. When they come home, though, manners can be forgotten at the door. From a ramifications standpoint, my wife and I would probably be much more upset if they took out a bunch of toys at their friend’s house and didn’t help clean them up than if they took them out at our house and didn’t clean them up. Wouldn’t it be great if we had consistent behavior at both?

Part of this is human nature. This is why the “team” mantra must be something that is continually communicated over and over. The company I work for has a huge emphasis on safety. Not a day goes by without safety being brought up in some discussion. If they were to stop communicating about safety, I’m sure the behavior would eventually trend toward less safety. The same holds true for a team mentality. You can’t spend one year emphasizing teamwork and expect everything to stay that way when you stop. If teamwork is important, make it a part of everything you do, and keep it a part of everything you do. If you want to start from a grass roots effort and you work in IT, stop using the term “the business.” Instead, find out what group in the business you’re referring to, and use their name. I know I still use that term on many occasions, so I’m going to eat my own dog food and try to improve from here on out.

I’m in a SAP session now. They’ve got their “End-to-End SOA Composition and Middleware Platform” picture up right now. It’s always nice when your vendor’s picture aligns with your own. Specifically, they have a separation between their Enterprise SOA Provisioning layer and their SOA Interoperability layer. Enterprise SOA Provisioning includes “Service and Event Enablement” and “Connectivity and Integration.” In SOA Interoperability, they have “Service Bus and SOA Management.” Thanks to the confusion between the ESB space and EAI space, these two layers are frequently combined, and I think they should be separate. The SOA Interoperability layer should be about mediating across a set of standards that the enterprise has adopted, which the enablement and integration layer is about hooking non-standard things into it. Push those pieces as close to the endpoints as possible, and put the stuff that’s required on all standards-based service messages in the middle. Unfortunately, they’ve now put up a slide on SAP NetWeaver Process Integration 7.1 and are positioning it to cover Service Bus, Service Integration, and SOA Management. So, conceptually they get it, but in terms of the product mapping, there could be some challenges if you don’t deploy it properly. If you separate out one PI environment for SOA Interoperability, and a second environment for Enablement and Integration, a lot of the potential risks can be mitigated.

Presenter: Benoit Lheureux

This was a decent overview of a whole bunch of things including composite applications, *-as-a-Service (software, platform, etc.). I would have preferred it if this presentation had taken more of an advisory, rather than informing, approach. There has to be a large number of enterprises represented here who have SAP, Oracle, or something else in their environment. Rather than going into depth on how to incorporate (e.g. best practices) these packaged applications into an enterprise’s SOA efforts (it did cover it, just at a light level), it went for breadth and spent a lot of time discussing packaged vendors and SaaS providers and their approach to SOA.

Presenter: Anthony Bradley

This presentation has started out with the unsurprising news that enterprise adoption of mashups is significantly trailing its use in the open Internet. He’s come up with a two-faceted classification model for mashups. The first facet is the integration pattern, which is one or more of the following (these aren’t mutually exclusive):

• Visualization integration
• Content integration
• Gadget page space co-location
• Gadget page space integration

The second facet is the application type, which can be one of:

• Personal portal delivery
• Packaged application extension
• Location awareness
• Panoramic awareness
• Situational awareness

All in all, I’m not sure what value this is bringing. I’ve posted previously on categorizations and taxonomies and how they need to have some purpose behind them. I’m not seeing the purpose behind these classifications. Typically, I’ve used classifications in reference architecture work where I try to map a particular type to particular constraints/patterns on the architecture and design, and I don’t see how these groupings do that.

He now had one slide that talks about the need to architect systems that allow them to be “mashable.” This I agree with, but again, it’s nothing new. We’ve been talking about this since the early days of portals, and you could even argue that it’s been around longer than that. He did present a proposed architecture for some of this at the end that may prove valuable to some attendees. Unfortunately, I don’t think he convinced anyone in the audience that mashups is something they should be thinking about. Personally, I think even the term puts some people off. I’d rather hear about the need to support “integration at the glass.” There’s too much of an association between mashups and just throwing something on a Google Map to make it have broader appeal, in my opinion.

Presenter: Jeff Hiatt, Prosci

Jeff isn’t with Gartner, so this session should be different. It’s already started well his use of these green and red cards we all have. He’s asked us a few questions and asked us to raise either the green or red cards. It’s made it very easy to see answers instead of the usual hand-raising approach.

His first statement on his slides is: “The speed of technology deployment will not be gated by IT innovation, but rather by the ability to manage the people side of technology changes.” Absolutely!

He just walked us through an exercise where we wrote down a project name, its purpose (why are we changing), the particulars of it (what we are changing), and the people that will need to change how they work (who will be changing). He pointed out that most technology professionals don’t consider the last column and really struggle with answering it, but yet not dealing with it can stymie the entire effort.

We just did another example where he asked the audience how many people have managing the people side of change as part of their job responsibilities, and there were about 10 people who said yes. That’s a big problem if this can be the biggest challenge in being successful.

We’re now walking through some best practices for managing change. The first deals with sponsorship. Jeff called out how sponsors need to be actively engaging throughout the lifetime of the project, building a coalition of support for the change. He especially emphasized middle management, as their research has always shown that middle management is the most difficult group to change.

Item two was having a structured approach the managing the change associated with the project. I don’t know that I’ve ever been on a project that had this, although, one challenge we have in IT is actually having visibility into that. If the change required is in the business side, often times that is invisible to IT. That, in and of itself, is a problem.

The third item is communications. Of course, face-to-face communication is important. Another important this is who delivers the message. The preferred sender of change messages is one of two people. For business messages, it’s the CEO or President. For personal messages, it’s the employee’s direct supervisor.

The fourth and fifth items were dedicated resources for change management and employee participation. We were all scoring ourselves as we went through this, and in the end, we used the red card/green card “visual vote” and it was very clear that about 95% of the people in the room were at risk for having poor change management. Definitely a very clear message, the real question in my mind is how to get IT visibility into the change that our solutions will introduce into the business. This strikes a chord with me, since I’m a big proponent on involving end users from my background in usability. Good talk!

Presenter: Daniel Sholler

It’s Tuesday morning, and I’m attending this one over breakfast. He’s just made an interesting comment regarding companies, using the insurance industry as an example. He stated that while most insurance company provide the same services, they differentiate based on how they organize. I was hoping he’d take this further and talk about how organization impacts SOA adoption, but no luck.

Another comment he made is that Gartner sees a correlation between companies that succeed with SOA and companies that have mature identity management practices. If identity can’t flow through all of your service interactions, you’re going to run into problems. I agree with that.

On to standards. He has another slide up that shows the different types of relationships an organization may have. At the bottom, a completely internal interaction relies on a private subset of information and process models. In the middle, a company talking to a partner has a closed agreement that defines them. At the top, a company interacting with a “cloud” service has an open agreement. Anyone interacting with the cloud can see the information and process models available. He’s then gone on to show how their is a spectrum of standards that one must be concerned with. Once again, no arguments here.

Presenter: Anthony Bradley

Anthony’s going to present Gartner’s new framework for building SOA business cases. He immediately began by stating that you can’t build a general business case for SOA. Rather, the point is to build an SOA business case for a particular business need. I can tell it’s the end of the day, as my attention span is dwindling quickly. This framework presentation is having the same impact on me as when I was first introduced to RUP. It appears to have a level of detail that makes it difficult to digest. The other thing that hasn’t been immediately apparent to me is why this isn’t a framework for building IT project business cases in general, rather than just SOA business cases. I’ll have to dig into the notes on this one, but right now, I’m a bit skeptical.