Bruce Robertson
Research VP
15 years at Gartner
27 years IT industry
Bruce Robertson is a research vice president at Gartner in the Enterprise Planning and Architecture Strategies (EPAS) group. He is also a chief of Research at Gartner, participating on the Gartner-wide Senior Research Board. Read Full Bio
by Bruce Robertson | May 4, 2011 | 10 Comments
It’s all the rage on Capital Hill — can environmental legislation take a new step toward reducing global warming by another round of cap and trade targetting new thresholds of air quality. As The Washington Post covered in Vehicle Emission Rules to Tighten, the US Federal government seems to be moving to enact legislation setting new mpg and co2 efficiency goals. It worked for acid rain, they say.
One interesting thing motivating industry to sign up to more stringent standards is that they get a national one, rather than separate ones for different states and cities. Imagine the cost of complying with too many different standards. Having a widely shared standard simplifies things, and surely reduces costs for the supplier and thus price to the consumer. Simply put, the design principles and requirements for vehicles are changing — providers must adjust to consumer demand.
This should sound very familiar to any EA practitioner. It’s hard to get any standards set or complied with. Does this case offer a good example we could leverage? Yes: play the role of mediator between provider and consumer. However, since EA is often seen as in the pocket of the provider (central IT, the one trying to get standards set), this often backfires.
How can EA remain inbetween the consumer and the provider? This is one great argument for having EA report outside of IT, not just outside of application development and infrastructure/operations — tho that too is a boundary condition best straddled too.
But, back to cap-and-trade. Maybe this can work for EA, particularly for waivers. You can break the rules, not follow the standards, but there is a cost. And, you can trade your set of waiver grants to others for a price. What would that price be? I get your waivers next year? I get some of your budget for my project? If a price could be created, trading might occur.
Then again, maybe this is half-baked. Maybe there aren’t enough waiver situations where such trading would be needed. How many projects do you even have to manage with respect to EA waivers. Too much extra work just to implement this. Worth doing for $millions, but not for a few bucks here or there.
Thoughts?
Category: EA Tags:
by Bruce Robertson | May 4, 2011 | 11 Comments
Next week I’ll be presenting on this “Enterprise Technical Architecture in 4 Slides” topic at Gartner’s EA Summit conference in London, and then again on June 22-23 in San Diego (event details in the links per event — follow the event on twitter using the #GartnerEA hashtag or me directly @brucemr).
We’ve noticed (since we review so many client architecture documents) that many EA practitioners have trouble generating a high level, conceptual, simple and direct statement of their enterprise architecture, particularly in enterprise technical architecture (ETA). This however is required — so many stakeholders will never read a longer detailed description of the architecture. You may of course still need to create deeper logical and implementation level detail about things — but these are mostly for those doing the building, not those who would use the resulting new system or standards. In fact, most if not all EA stakeholders need — at least at first — a simple summary of just what the architecture is.
In this presentation I’m going to describe one effective way to handle this problem: just use a 4 slides technique. What 4 slides? Future state, current state, gap analysis and migration plan. Not surprising really — these are the base deliverables of any EA discipline at a high level. There are of course many best practices and indeed alternatives to the representations of such information to consider — I’ll discuss those too. But, the basic point I’m making is that you can do it in 4 slides. You should be able to do it in 4 slides — and if you can’t, then you’re not doing a good job at sending key yet simple messages about your ETA.
Ironically, however, I have more than 4 slides in my presentation. Oh well. I tried to make this the shortest Gartner presentation ever, but some overhead creeps in! The meat is the 4 slides, however.
Do you have a 4 slide approach like this for your overall ETA story, or more specifically for more specific areas (a given technical domain strategy, a technical service architecture, and technical pattern architecture)? How do you make the points simple enough to speak easily to key constituencies and stakeholders, the very ones who just don’t want to hear much about why you’re proposing this or the details of what’s inside?
Category: EA Tags:
by Bruce Robertson | May 4, 2011 | 9 Comments
Next week I’ll be presenting on this “Is Amazon Your Architecture?” topic at Gartner’s EA Summit conference in London, and then again on June 22-23 in San Diego (event details in the links per event — follow on twitter using the #GartnerEA hashtag or me directly @brucemr). My goal is to discuss the way Amazon has architected their store and logistics applications (sites, systems, solutions) with an extreme SOA architecture, and then how they’ve taken a similar extreme services architecture approach for infrastructure services with Amazon Web Services (AWS). For many organizations both the application and infrastructure architecture approaches are useful, depending on the problem.
FYI: I’m only tangentially suggesting enterprises should leverage AWS or Amazon’s store and other “SaaS” like application options. The point here is should their architecture (particularly technical) be used inside the enterprise. For many organizations, I think the answer is yes.
What do you think? Does your organization have solutions that require extreme SOA?
I think many do — and Amazon’s store is something not unlike many of your enterprises might actually try to build, so it’s a good example to use. Amazon’s lessons learned are worth hearing about, I believe.
However, many of us have applications that can NOT take an extreme SOA approach without extensive modification (or complete reworking, more likely), and there’s no money for that any time soon. For these non-extreme applications, should we then consider using AWS? The answer is: sometimes. Monolithic apps that can’t run in parallel on separate virtual machines (and as recent EBS and S3 outages have reminded us — in separate availability zones and regions) are very risky on the infrastructure services Amazon and other providers offer today. However, there are times when the risks are worth it — such as for test and dev work. Depends on the problem and the risk tolerance of the enterprise. Even with the recent Amazon outages, some organizations can live with a system not being up for a whole day. It all depends on the problem and the risk tolerance of the organization.
Still, the real lesson most enterprises should learn from AWS is not to use external cloud services alone, but to structure their own technical services or infrastructure service offerings not unlike AWS. Look at how Amazon defines their AWS portfolio. Look at how they describe each service (not much on the provider, but lots on how to use it and service levels offered). Really peruse aws.amazon.com to see how they market their shared services.
Can your IT organization do this? Have you described the “what does the customer get” part of your shared technical services as well as you’ve defined how they are built or provisioned?
Category: Cloud EA Tags:
by Bruce Robertson | December 6, 2010 | 10 Comments
At Gartner’s Data Center Conference this week in Las Vegas, I’m hoping to get lots of input on how infrastructure leaders manage infrastructure investment. I’m particularly interested in seeing if similar portfolio management techniques are leveraged, as for example in the fairly common discipline of Application Portfolio Management (APM). In fact, I’m hoping to discover what I believe are current practitioners of and best practices for a new “infrastructure portfolio management” (IPM) discipline.
I have my own ideas based on my experience to date with infrastructure planning and technical architecture planners I’ve spoken with over the years. But, frankly, I still haven’t seen much focus on a holistic approach to planning particularly the shared infrastructure services with portfolio management techniques. Since these investments are made separately from any single application, they are hard to get funded yet critical to achieving new efficiencies and effectiveness in infrastructure.
I do propose that planning a set of shared infrastructure services – including WAN, LAN, voice, as well as mainframe as the most mature cases – is getting to be more critical as there are more and more shared services. Today, most IT organizations have shared storage, shared compute for platforms other than the mainframe using virtualization technologies, shared security services (like identity or firewall), shared middleware based infrastructure (shared portals, shared ESB, etc.) and so on. Most organizations admit they have more and more of their IT spend (and most of their infrastructure spend) tied up into these systems. But, they don’t yet apply APM-inspired portfolio management techniques to manage the investments in these assets.
I do propose that infrastructure planners and technical architects must leverage this set of techniques moving forward. They should show a portfolio of the services, defined with both provider and more importantly consumer viewpoints well documented and agreed upon. Then, they need to develop a road map for moving that portfolio of investments from the current state toward the future state. They need to make sure these are integrated or synergized with the APM planning too.
Instead, we seem to attack this problem one shared system at a time, without a concerted effort to see a portfolio level view. Why not leverage proven APM techniques? Why not describe the intended upgrades for the shared services as being run or grow or transform the business investments? Why not review the road maps for change with key stakeholders, including those focused only on applications, only on APM, or only on projects.
I’m sure some of you are doing more than one system planning here, but exactly how do you do it? I’d love to hear the stories. If you’re out here at the Gartner Data Center Conference this week, come by and setup a 1-1 with me and tell me your story. If you’re already overbooked at the Data Center Conference or aren’t out in Las Vegas, please don’t hesitate to comment publicly on this blog or privately email me (bruce.robertson@gartner.com) with some sense of what you’re doing. I’d like to highlight a few best practices from the field in my research soon, and frankly I need more examples of what’s working and what’s not. Perhaps you think I’m off my rocker on this – then tell me why (but also how you “manage your investments in shared infrastructure”).
Thanks. I look forward to discussing this with you all.
For more, see past blog: http://blogs.gartner.com/bruce-robertson/2010/02/09/ipm/.
Category: EA Tags: IPM
by Bruce Robertson | October 15, 2010 | 10 Comments
Many of you who read Gartner blogs and specifically our EA team’s blogs will be attending our Symposium/ITxpo conference next week. As I was using the “My Agenda” function to setup my own time, I thought it would be wise to mention a few things we’re covering on EA topics at the conference for others attending. EA analysts at Symposium Orlando include: Philip Allega, Scott Bittler, Betsy Burton, Nick Gall and David Newman.
Nick and David are both discussing Hybrid Thinking, then Nick adds EA teams and EA maturity and David adds Information Sharing. Philip is discussing EA for CIOs, EA and portfolio management, and ITScore. Betsy is discussing EBA and EA governance, along with Pattern Based Strategy. Scott is discussing EA principles, EA communications, EA requirements and the EA Hype Cycle. I’ll be floating around, meeting with clients and prospects and otherwise meeting all of you attending at the various functions. We’d all love to talk to you if you’re attending, so do please say hello. There will be EA birds-of-a-feather seating at breakfasts as well.
The full layout of different choices (sessions, analyst user roundtables, workshops, and case studies) is listed here. The sessions are described in the “My Agenda” function here. A few things that are new that you may want to check out include:
- ITScore — we’ve updated the EA Maturity Assessment, and Phil will be discussing this 9am Tuesday. Clients can prepare by reading this in advance: ITScore for Enterprise Architecture (G00205016)
- EA Hype Cycle — we’ve created this for the first time, and Scott will be discussing it 12:30pm Tuesday. Clients can prepare by reading this in advance: Hype Cycle for Enterprise Architecture, 2010 (G00201646)
- (check the my agenda function to confirm availability (some workshops and roundtables may be full already)
Finally, if you are attending, please don’t hesitate to setup a one-on-one (1-1) meeting with me or our other EA team members attending: Philip Allega, Scott Bittler, Betsy Burton, Nick Gall and David Newman. You can schedule as you need at the Dolphin Pacific Hall scheduling desk or at interactive kiosks around the event.
See you there!
Category: EA Tags: symposium
by Bruce Robertson | September 16, 2010 | 9 Comments
The Washington Post recently published an article discussing the difficulties the Commonwealth of Virginia has had with it’s IT systems: Crash of Va. computer network has implications for tech world, state politics. Apparently, something went wrong in the outsourced IT capability managed by Northrup Grumman in a $2.4B contract. It has impacted multiple agencies, including the DMV where 74 offices were unable to renew drivers licenses for many days. Quoting: “In all, computers at 26 of the state’s 89 agencies were affected.”
What interests me from an EA perspective are two things.
First, I’m so happy to see the dirty laundry aired with some level of transparency. Public sector enterprises “suffer”‘ from this openness, but I think it’s a good trend that we all should be more transparent. These are real discussions we must have about IT (and EA) value — or lack thereof. Too often, any kind of failure is immediately hushed up, and festers as stories told at the water cooler — never put on paper or discussed openly. We need to learn from our failures.
Second, I’m amazed by the description the newspaper and the words people it quotes actually use to describe the problem that occurred. Actually, there isn’t one description, there are many — and perhaps that should NOT surprise me, but it does. Here are examples of how this problem is described in just this article (and I quote, with my own underlining to highlight different terminology):
- “The data storage unit that failed in a warehouse outside of Richmond last week, wreaking havoc in the computer networks of a number of Virginia agencies for more than a week, is a ubiquitous bit of technology …”
- “The crash — still baffling to state officials — exposes the vulnerability of modern, massively complex interconnected computer networks“
- “the worst network failure since …”
- “computers have been down”
- “In all, computers at 26 of the state’s 89 agencies were affected.”
- “Chief Information Officer Sam Nixon said Thursday that the problem began Aug. 25 with the crash of a pair of three-year-old memory cards — one was supposed to back up another.”
- “That led to 485 of the state’s 4,800 data servers being knocked off-line.”
- “the storage units are fundamental building blocks used to hold the mass databases of information necessary to run complex organizations in a digital age”
- “A blistering legislative audit released in October found that the computer system had caused problems at almost every state agency that uses computers.”
What crashed: data storage unit, computer networks, networks, computers, memory cards, data servers, storage units, mass databases, computer systems?
Are these people all talking about the same thing? The same problem? The same effect and cause? Yes, but … it certainly doesn’t seem like that. For EA practitioners, let this be a lesson to us all: there are so many different views of things. In EA, we have to understand and speak to them all.
One consistent thread: what failed was some kind of technology and the outcome of this was reduced services to citizens (DMV and other examples are cited). This we can all agree on. There is a set of related things that each can be named as the cause of the failure — here it might be: memory card, storage unit, computer systems, mass databases, computer networks all in a dependency thread that gets increasingly larger as the dependencies keep piling up. This was apparently shared infrastructure (a SAN) that many applications (and their computer systems) depended on. This is a technical architecture thread (or pattern, if repeated in many actual solution threads). We’re left asking if too many eggs were dependent on a single basket, and can any single basket ever be fully fault tolerant.
Here’s my challenge to you: Can you define the dependency thread of failure in your enterprise?
If such a variously described “thing” failed in your environment, which eggs would be broken when the technology basket fails? Would you already know which 1) systems, 2) applications, 3) people, and most importantly 4) business services are impacted? For this, EA information could be leveraged — you’d know which business services (FEA’s BRM or better SRM, business architecture function or service models, etc.) are dependent on what other services or technologies or implementations. You’d be able to do a quick analysis or risk assessment to show the extent of an outage’s impact on the eggs in the basket (predicted or actually occurring).
Perhaps this case example suggests some opportunities for what EA can do for key stakeholders. Here, the EA failure would be not taking advantage of a crisis to show the value of the EA work.
I have no visibility into the Commonwealth of Virginia’s EA program (but I have met with people there over the years), so if anyone has more info on what happened in this case from an EA slant, please share. Or, just any other cases where EA information helped in managing a crisis — everyone would like to hear about some successes.
Category: EA Tags:
by Bruce Robertson | August 24, 2010 | 5 Comments
Over the past few years, conversations with my sister about architecture have started with her reminding me that she’s an architect and I’m not. She’s the building type. Got certified and licensed. Advanced degree. She believes that we shouldn’t even be using the term architect in our IT centered world — since they have a licensed use of the term for their kind of professionals, no other professionals should use it.
But this week over dinner she has relented a little. She actually used the term information architect in a sentence, a positive or at least not negative sentence. I don’t think it was just because I paid for dinner. Then, she forwarded me this article:
http://www.architectmagazine.com/architects/im-an-architect.aspx
Apparently she wasn’t the only one of the building kind that has wondered what “our kind” were up to, usurping their job name. But, as the article points out, perhaps the building kind is getting used to the idea of enterprise or IT or information kinds of architects. In fact, the article notes that it’s flattery of a sort to have your name co-opted.
Granted, EA has taken it’s cue in many ways from the building architecture discipline. The city planning metaphor for standardization. The pattern idea adapted from Christopher Alexander (et. al.) in A Pattern Language: Towns, Buildings, Construction. And so on.
Did we realize we stole the name and that others actually cared about our theft?
Maybe we do want to get to a point of having strong meaningful useful certification for enterprise architects. But, when we get to that level, I don’t think we’ll get to just call ourselves architects. The name’s already taken, professionally. That’s going to make things interesting, since it has been my experience that many IT roles have added the architect label to them to gain … a pay raise, I guess. We have a lot of architects in IT — and we’ll all have to get some adjectives to distinguish ourselves. At least enterprise architects have their adjective. Now if I could just get my sister to use that in a sentence. That may take another dinner. Maybe even drinks.
Category: EA Fun Tags:
by Bruce Robertson | June 22, 2010 | 1 Comment
Vivek Kundra, the US Federal CIO, published a “State of Public Sector Cloud Computing” report on May 20, 2010: http://www.cio.gov/pages.cfm/page/State-of-Public-Sector-Cloud-Computing. It lists a variety of cases where federal and state and local entities are piloting or using cloud computing based solutions, both public and private and various scenarios in between (just gov’t, just military, hybrid, etc.). It’s interesting reading.
Recently at Garter EA Summit conferences, I have discussed how EA itself should embrace cloud computing as a new technology or approach and presented case studies showing how organizations are starting to see the value. It is as revolutionary as SOA, yet likely to be as misunderstood. However, rather than rehashing here a litany of definitions for cloud computing, I’d like to mention a few of the case studies in the report. The efforts span IaaS (DISA’s RACE), PaaS (DISA’s Forge.mil) and SaaS (USAF’s PSDT). Some are internal using cloud computing enabling software (e.g., CollabNet), others are using public cloud services (e.g., Amazon EC2, salesforce.com, RightNow), and others various scopes and hybrids in between (e.g., DISA is acting as the service provider for other agencies). In each case the value propositions include lower costs, more elastic transaction load support, faster transactions, better availability, and in some cases greater collaboration across agencies (Forge.mil, for example). Some are already running (GSA’s usa.gov site now hosted on Terremark’s Enterprise Cloud service), but many are just planned for implementation and rollout in 2011 (e.g., DoI’s cloud service-based email). And, that’s just from the federal cases.
At Gartner we’ve tracked these and other private sector cases, and in my presentations as well as those of other analysts, we’ve tried to show real cases of using cloud computing services. Of course, it’s a new approach that deserves particular consideration as a choice for technology (IaaS, PaaS) and indeed full solutions (SaaS). Yes, there are risks — but these case studies are proving that even careful public sector customers are taking those risks. Please check out Gartner analyst Andrea DiMaio’s blog — he’s the lead for us covering public sector cloud computing for us, and his blog is well known for watching this market and it’s users to see what’s working and what’s not.
Now, on to my real question for you: have you ever written a case study about cloud computing service use within your organization? Have you ever written a case study about ANYTHING concerning EA value in your organization? Our research suggests that most of you have not ever done this. Many of you are ignoring or just undervaluing the results of a strong effort to communicate about your EA successes.
I suggest two things:
- Look at these simple approximately 3 paragraph case studies as an example for you to follow
- Write 3 internal case studies in the next 3 months (no taking the summer off!)
Finally, if you’re really brave: 3) email me a copy or post them on a blog and email me about them. I’m very interested in publicizing good case studies for EA value — be they cloud centered or not. Got one?
Category: Cloud EA Tags:
by Bruce Robertson | April 27, 2010 | 215 Comments
I was intrigued by this recent article The New York Times: We Have Met the Enemy and He Is PowerPoint. It notes that “PowerPoint has crept into the daily lives of U.S. military commanders and reached the level of near obsession.” Give it a read. Others have discussed this as well — my Google search turned up many such references (ZDnet).
However, it does get worse. As I’d vaguely remembered and still found a reference, Wired reported in 2003 (in Military Faces Bandwidth Crunch) that bandwidth in the U.S. military was being eaten up as fast as it was added. ”Video was one reason. But so was the military’s predilection for PowerPoint presentations. ”Some say that 70 percent of that bandwidth was consumed by PowerPoint briefings,” Lord joked.” But, it’s not always a bad outcome. Sometimes, however, the PowerPoint slides are seen as the wake up call: The Pentagon’s Scary PowerPoint in Time (2006) and in Slate (2002). Even in the U.S. military.
Does this same criticism of PowerPoint overuse apply to Enterprise Architecture? I bet most of us would agree that one of if not the most used tool for EA is PowerPoint. So, is that good or bad?
I think PowerPoint is GOOD for EA. I’m constantly trying to get EA people to stop writing big whitepapers and convert to a few good PPT slides. Not the big hard to read or understand scare slides (the one from this article!), but simple explicit ones that move comprehension forward. If you can’t draw a picture to explain the basics, the whitepaper is not much further help. So, start with the simple pictures. If you need to go deeper, then go — but only after you’ve confirmed the big concepts using simple presentations. If you can’t show the conceptual, your implementation level details will be LOST on most, if not all, readers — and of course on those who will NEVER read the bloated pile of paper you’ve just delivered. No wonder EA has a bad rep — too many words (and generally deliverables) that no one reads or uses.
I also believe the real tenor of the U.S. military worries about PowerPoint are for misusing it to recreate those 100 page whitepapers but just in PowerPoint form. Too many slides is just as bad as too many pages. Remember the KISS principle: Keep it short, stupid! Indeed, as the US military says, get to the point.
One Gartner client has a 100+ slide deck that she carries around to show people her firm’s enterprise architecture, but … and this is a big but … she never shows all that to anyone. She just shows the few slides from it that are appropriate to the stakeholder she’s talking with — just the use cases for the EA that matter to that person.
So, while I do think PowerPoint does not kill EA, certainly poor conceptual level work can, no matter how it is expressed (PowerPoint or other medium). Complex slides are NOT helpful; simple ones can be. KISS, people: keep it short and simple.
Category: EA Tags:
by Bruce Robertson | February 9, 2010 | 14 Comments
I’m working on a presentation for Gartner’s upcoming EA Summit in Las Vegas (April 14-16, 2010) and London (May 17-18, 2010) about an aspect of what we call Enterprise Solution Architecture (ESA). While application portfolio management (APM) is one reasonably mature version of solution portfolio management in ESA, we extend the idea of managing investments in application assets to infrastructure infrastructure assets. We call this infrastructure portfolio management (IPM).
Granted, the spend or investment in some infrastructure is done within the application portfolio — that infrastructure that is dedicated to a single application is often included in the application’s change plan or road map and most importantly budget. The impact of enterprise technical architecture (ETA) work on traditional APM-oriented change planning within the enterprise is perhaps the most common EA activity — getting guidelines and standards for technologies and products defined so that applications can move to more standard and hopefully better technologies, then applying them as projects to add new or upgrade existing application investments are hatched and delivered. But, I’m not talking about that part of the infrastructure.
I’m focused on planning change or investment in the infrastructure that is NOT in the application portfolio — the infrastructure that is NOT dedicated to one particular application. I’m focused on shared infrastructure. This shared infrastructure should really be thought of as a set of shared infrastructure services (e.g., fully architected solutions including operational support and SLAs, not just the ETA sw/hw parts). These shared infrastructure services certainly can be managed or planned leveraging the portfolio management — and specifically more mature APM — techniques. That’s what I’m discussing in my presentation: how to manage or architect such solution portfolios and how to architect the dependencies between them.
Anyone out there doing this form of infrastructure portfolio management (IPM) or infrastructure solution portfolio management (ISPM)? I’d love to hear it. I’m looking for more case studies to quote.
Is anyone even doing what ITIL v3 calls IT services management (ITSM), which I think is related but not quite the same? Our experience is that this is not the case yet for most ITIL centered organizations — this v3 level of complexity is still a future goal. But, I think what I’m calling IPM (or ISPM) is related and the two should be integrated. What do you think?
Category: EA Tags: ESA, ETA, IPM, ITSM, portfolio management
