Todd Biske: Outside the Box

Archive for the ‘Conferences’ Category

This session is being presented by Tom Scholtz. His opening message is that we have to avoid one-size-fits-all security solutions and that we need to think strategically, otherwise we’ll always be behind the risk management curve. The approach he’s advocated is very consistent with EA: Plan, Build, Govern, Run, and back to Plan again.

He’s now talking about the organization model for information security in the future. The first item is that he recommends moving the corporate information security team outside of IT to increase the message that security is a corporate issue, not just an IT issue. This team would be involved with risk management, policy management, program management, business continuity management, architecture, and awareness. This group would report to a Corporate Risk Manager. Within IT, reporting to the CIO, there would be an IT Information Security Team looking at risk assessment, design and implementation, disaster recovery plan, security operations, and vulnerability assessments. Within business units, they would have local continuity plans, awareness, and policy management. Tying it all together is governance.

He’s now recommending that we become more process centric about security. In the vertical dimension, there are four key protection processes:

• Identity and Access Management
• Network Access Control
• Vulnerability Management
• Intrusion Prevention

In the horizontal dimension, he has strategic processes:

• Risk and Policy Management
• Security Architecture
• Business Continuity
• Relationship Management

Not much more to report on this one, as I need to skip out early and check out of the hotel to catch my flight home. This definitely looks to be more appropriate to an ISO manager than someone closer to the technology like me, but I’ll have to review the notes in the conference materials to get more detail.

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.

I’m sitting in a case study session on SOA Governance. Barney Sene, VP and CTO of Ingram Micro, is currently speaking and just had an interesting slide up. Because they are a global company, one of the things they always do is examine any proposed service (documented through a Service Requirements Specification – SRS) for specialization that may be required for global requirements, versus the context in which that SRS may have been created. I now work for a global organization, and now clearly understand the need for this. I have firsthand knowledge of a business service that will have differences in how it must operate based about the geographic regions involved. Barney’s slide demonstrated how the SRS provided a significant percentage of the final definition, but these other factors like globalization chipped away at the remaining 20%.

From a governance perspective, what I liked about this was that it presented an approach that didn’t mandate, but rather encouraged appropriate behavior. If the company has stated “We are a global organization” rather than acting as a collection of regional organizations, then every project should be asking the question, “Are there any regional nuances that must be factored into the architecture and design of what I’m producing?” This example also got me thinking about what other factors should be explicitly encouraged in this same way, simply because people aren’t used to thinking that way. Globalization makes perfect sense. Security also makes sense. We have to realize that many designers and developers are primarily concerned about the functionality at hand, and need some encouragement to think about factors “outside of the box” that may influence both the non-functional areas as well as the functional areas. Because this is a shift in thinking, it must be encouraged first, enforced second. Dangle the carrot, and only use the carrot when necessary. What other items belong on the list that can take a service from an 80% solution to a 100% solution?

On Wednesday, Patrick Lencioni, author of The Five Dysfunctions of Team, and other management fables gave the morning keynote. It was an excellent talk. Having read both Five Dysfunctions and Silos, Politics, and Turf Wars, I recommend picking up all of his books if you have an interest in making your organization work better (and you should). I picked up his latest book, The Three Signs of a Miserable Job and Death by Meeting after his session and had a nice conversation with him about some experiences.

It has been a couple years since I attended a Gartner Summit, and now I’m remembering past experiences. Many of the subjects are presented at a very high level (which is appropriate for the audience at a Gartner conference), and many of the subjects are ones that I’ve spent a lot of time researching on my own. I’ve been trying to attend more sessions this time on subjects that I don’t know much about, so the experience has been better. What I’m wondering, however, is why more of the people attending (and there are easily more than a thousand of them) don’t start reading my blog and that of my colleagues in the industry to pick up this knowledge (in addition to attending conferences like Gartner Summits) and even more importantly, ask questions. Yes, reading my blog doesn’t allow you to travel to some interesting location, but I like to think that the content I provide is appropriate and meaningful.

I hear many questions getting asked over and over at these conferences, and it’s apparent that there’s a very large group out there that simply don’t look for the answers to their questions beyond these conferences. Rather than look for the information, they look for an information source. Guess what folks, this is the information age, and there’s a wealth of it out there. I built up my knowledge not only with research from Gartner, Forrester, Burton Group, ZapThink, and others, but also by reading whitepapers, articles, blogs, and anything I could get my hands on. You can do it as well. Gartner, my blog, conferences, webinars, etc. are all sources of information, and the most important thing is to find information that hits home for you and seems applicable to your environment. If it’s one case study instead of one hundred, it doesn’t matter, as long as it is relevant to your scenario, not someone else’s. Gartner is an excellent source of information, and I like to think that this blog is as well. Use both, and then some, and lets keep things progressing forward so at next year’s Gartner conferences we’re talking about new questions, rather than rehashing the same ones.

I attended a session from Michael Blechar titled “The Yin & Yang of Processes and Data: Which Will Be King of the Next Generation Applications?” A big title, and as a result, Michael covered a lot of topics. While there wasn’t any new information for me, I would say that this was one of the better big picture overview presented at the conference. Some of the topics he hit on:

• The challenge of multiple metadata systems, and how some of the vendors are approaching it, in particular IBM. He specifically touched on CMDBs (Configuration Management Database), Service Registry/Repository, Software Development Assets, Database Metadata Management, and more. IBM’s approach is to provide a collection of metadata services that reside above all of this systems, providing a federation layer. Hmmm…. this sounds vaguely familiar, I think I called it Master Metadata Management and spoke more on it here.
• The challenges in determining when to use them versus pushing the logic up into a service layer. It discussed the importance of service ownership.
• The importance of information modeling and its importance in SOA.
• The importance of service ownership/stewardship.
• The importance of enterprise architecture operating as a team, and not having silos of business architecture, technology architecture, and information architecture that don’t talk to each other.

Overall, this was probably a good session for many people and hopefully helped them see a bit more of forest for the trees.

The Power Breakfast is over and done. If you saw me there, hopefully you got something out of the conversation, although it was unfortunate that the session wound up being four independent case studies without a lot of time for audience questions, rather than a discussion among the panelists and the audience. Despite this fact, there were some good points that came out, and I wanted to highlight the ones that struck home with me here:

• First, as the preliminary results of the SOA Consortium funding survey have indicated, there’s no uniform initial approach to SOA. Some leverage an SOA program, some expect service development out of existing projects, etc. One of the panelists, Leo Schuster from National Bank, indicated that they had an SOA Program. In my experience, I’ve never encountered a funded program whose sole goal was to produce SOA. I’ve always worked with business projects/programs that wanted to leverage services as part of their efforts. Personally, I prefer the latter, because as Victor Harrison from CSC pointed out, programs end. Will your SOA efforts ever stop? They shouldn’t. So, while you may have solved the initial funding problem, you haven’t solved the ongoing funding problem.
• Second, metrics are critical. Every single one of us mentioned metrics. Without them, how can we say that we’ve accomplished anything? The oft-mentioned notion of agility is frequently associated with the time to deliver a particular solution. To show that we’re more agile, we need metrics of how things have been and how things are in the future. Beyond efficiency metrics, there’s also metrics associated with service consumption: number of consumers, usage by consumers, min/avg/max response time, etc. In my own experience, merely making these metrics available, and now at a finer level of granularity than the entry points into a web application were very beneficial. This visibility didn’t exist before, so anything was better than nothing. If you’re already collecting this, now you can start to do baseline comparisons to show improvement.
• Third, service ownership is key. It was great to hear someone else say that the project-based culture of IT can be in impediment to SOA success. While your SOA shouldn’t have a lifecycle, individual services do have a lifecycle. If you simply have someone who is responsible for service lifecycle management, you’ve got the key piece of the puzzle for many of the discussions around service granularity, funding, etc. If you don’t have a service owner independent of the consumers, then each consumer is going to try to push things in the direction that has the most benefit for their project, but yet no one will own the service. This in-fighting can be very detrimental to SOA.
• Finally, lets get Service Portfolio Management (SPM) right from the get-go. There are many sessions here at the summit concerned about application portfolio management. We’re all behind the eight-ball here as all of these applications have been built/bought over 5, 10, 15, 25, … years without anyone managing them as a whole. The last thing we want to do is repeat the process all over again with services. We’re at the early stages of SOA and can now do it right. Anyone saying that they don’t need a registry/repository yet because they haven’t reached “critical mass” is potentially making a big mistake. They only need to look at their struggles in trying to do application portfolio management as an example of the path they are heading down.

To those who got up early for breakfast and attended, I hope you found some nuggets in the presentation that were valuable from me or from the other speakers. I’d be happy to have followup conversations with anyone who felt like their questions are still unanswered, or those who want more depth on some of the things they heard.

I attended a session on assessing maturity in IT given by Susan Landry. She outlined their maturity model which covers eight different dimensions. The maturity model has familiar levels if you’ve looked at my work, CMMI, or COBIT. Level 1 is ad hoc, level 2 is repeatable, level 3 is defined, level 4 is quantitatively managed, and level 5 is optimizing. The eight assessment areas are:

1. Application Portfolio Management (APM)
2. Project Portfolio Management (PPM)
3. Staffing, Skills, and Sourcing
4. Financial Analysis and Budgets
5. Vendor Management
6. Management of Architecture
7. Software Process
8. Operations and Support

The most interesting part of the discussion, however, was a single slide that discussed the interdependencies between these areas. For each pair of areas, the relationship was classified as either highly interdependent or moderately interdependent. Having done a multi-dimensional maturity model before, a big challenge is in determining whether or not it makes sense to get scored high in one dimension or low in another. In my SOA maturity model, I typically found that when scores were two or more levels apart, it was probably going to cause some imbalance in the organization. If the scores were even or a single level apart, it was probably workable. What I didn’t do, however, was to explore those inter-relationships and see if that theory uniformly applied. While Gartner didn’t provide a lot of depth in the inter-relationships, they did at least make a statement regarding it which can provide a lot of assistance in determining how to interpret the scoring and what actions to take.

In this session, Frank Kenney and Val Sribar, are discussing agility and application development in the context of a fictitious fable of a web unit in a business organization that is operating in an agile manner and how it works with the traditional application development organization. While I find the fable a bit far fetched, since I’ve yet to see a business unit pushing agile processes on IT, it’s usually the opposite, there is one key point that they made. They called out that not all business units may be ready for an agile approach, simply because they don’t change that rapidly. Hopefully, this will be a common theme throughout the conference. Any approach that claims to be one size fits all is probably going to run into problems. Whether it is agile, REST, Web Services, SOA, EDA, etc., there are always scenarios where it works well, and scenarios where it doesn’t work so well. A key to success is knowing not only how to apply a particular technique, but knowing when to apply it.

Further in on the presentation, they went through some different areas and discussed how they contribute to agility. In the subject of business process actions, they called out that there should be a single business person clearly in charge of a particular process. I think this applies not only for processes, but for services as well. There needs to be a service manager for each service in the organization. An individual may manage multiple services, but without a service manager, there will be problems.

On the subject of reuse, Frank Kenney pointed out that incentives, metrics, testing, methodology, and inventory management (registry/repository) is necessary to make it a reality. I think this is a good list, although I would have liked to see marketing included. While a registry/repository and methodology do focus on the consumption side, if a service or reusable asset is placed out there in a way that makes it difficult to find, the burden is on the provider to improve it, which involves marketing.

Near the end of the presentation, Val and Frank presented an “Application Group of the Future.” Val called out breaking out groups for User Experience, Business Processes, Business Information, an Integration Competency Center, Business Relationships, Software Quality, and Information Infrastructure. These groups would all be operating in an agile manner. In addition, the traditional development groups would also exist. These groups would all leverage common environments to support their efforts. There was one thing about this picture that I disagreed with, which was the placement of SOA. They sprinkled the entire organization with SOA experience, which makes sense, but they didn’t call out the separation between organizations focused on service consumption and organizations focused on service production. If anything, service production (unless it happened to be an automated business process) was buried in the tradition development group, and I don’t think that will cut it. On the bright side, one of the things that they called out which was very interesting, was the need for dynamic budgeting. Val made a comment that the web and mobile applications are challenging the way we book business early in the presentation. This need for dynamic budgeting is an analogous example to how a new agile IT, challenges the way we traditionally do budgeting. Annual budgets won’t cut it, we’ll need to make it more dynamic and responsive in real-time.