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 | September 10, 2009 | 27 Comments
I’m presenting at two upcoming Gartner EA Summit events in
London (Sept 14-15) and
Orlando (Oct 7-9) on the topic of “Architecting for Emergence: New EA Models Embracing Change.” I’ll also be describing case studies for Emergent or Middle-Out EA approaches in separate presentations.
Gartner’s EA team has been discussing emergent or middle-out EA approaches (we’ve even called them “EA Lite” at times) for some time, but this way of defining EA is new or unfamiliar to many EA practitioners we talk with. My goal in the two presentations at the two EA Summit conferences is to lend some depth in both theory and practice (case studies) on how this EA approach works.
Basically, EA teams should define interoperability built on information sharing interfaces, rather than just technology (ESB, SOA’s WSDL/SOAP, etc.), that are more generalized than before, and thus more reusable both for defined needs as well as future serendipitous unplanned requirements. By defining key base data interfaces, and perhaps also more complex process on data interfaces, you build in the ability to enable interaction between systems EA teams have little control over. While this is a return in a way to integration as a prime EA theme or goal, this time the effort starts with defining enterprise information likely to be shared or common across the enterprise, then to services that enable easy access, and only then to technology needed to support this interaction.
The generalization of interfaces may be defined top down (via traditional EIA work) or bottom up (via examining existing SOA interfaces and other data). Either way, the best generalized interfaces then must be sold so that they are reused in systems over time — sold, not just mandated.
This approach to EA enables some organizations to make headway in enabling significant business opportunity even in the face of very complex current states. It also is the foundation of connecting the enterprise to it’s business partners and customers.
We’ve published a great deal on this approach — if you’re a client, you might start with this note: “Architecting the Emergent Enterprise: New Game, New Rules” (
G00160427).
If you’re attending these events, please do come join me. We’d love to hear if you are doing some of this kind of work.
Category: EA Tags: EA lite, emergent EA, middle-out
by Bruce Robertson | July 10, 2009 | 22 Comments
Found this post while lurking a #EA twitter search: ARCHITECTS ARE GOING GREEN (Cute pic, btw.)
Are architects going green? IT is trying, but I don’t really hear many EA clients I talk to bringing this up. There are certainly things to do, and green can mean lower cost as well as sustainable. So, why no real focus?
I have an opinion, but it’s only that: it’s deemed to be too low level. But, if the enterprise you’re architecting actually itself cares about green, I bet you ARE focused on this. You certainly SHOULD be. The alignment of green IT projects/future states to corporate business strategy could be the last straw that breaks the camel’s back of funding change initiatives to bring the EA to real life. If they don’t care about green, then the cost advantages could also prove effective. Either way, green would be a nice color to paint your EA.
So, why is EA not more concerned with green? Do you have any examples of where using green helped you?
Category: EA Tags: EA
by Bruce Robertson | July 9, 2009 | 21 Comments
Yet again, my colleage Lydia Leong has mentioned something that reminded me of something in EA. In her “A hodgepodge of links” blog entry, she mentioned enjoying Malcolm Gladwell’s “Priced to Sell: Is free the future?” retort in the New Yorker to Chris Anderson’s thesis in his book Free — that information will be free. Interesting discussion: read it and savor some good pointed critique. (Me: I do love a good rant.)
My version of this architecting “free” started when I was first introduced many many years ago (1996 maybe) to Enterprise Architecture. I attended an EA Seminar by Larry Deboever, then at META Group where I worked before it was acquired by Gartner (where obviously I work now). One of his most common challenges to new architects was to get their heads out of the sand and think about very different worlds the future could bring. A particular exercise he used was to answer this: how would you design applications differently if the network were free and had unlimited capacity. The answer of course is: you would make VERY different decisions about how to architect systems. Imagine that!
The Gladwell critique of Anderson’s notion of “Free” brought this all to mind again. When I heard Larry’s design challenge, I was on the networking analyst team. I knew perfectly well that this could never happen: networks would not be free and networks would not have unlimited capacity, and certainly not both. So, I always wondered really how far such thought experiments could go. Anderton’s book certainly provides some specific examples of how it has worked, but there are others where it has not (as Gladwell points out). While it is true that networks are much cheaper and much higher bandwidth than ever before (and really, compared to 1996, they might seem free and unlimited — during 1999/2000, I almost thought we’d get there, but CRASH!), still they are not free or unlimited. As I write this I’m paying to use a network (Verizon FIOS, $39.99 / month for high but still limited bandwidth) and so is Gartner paying for connecting our bogging system to the Internet so I can use it from my home office.
So, I agree with Gladwell: money has to be made somewhere. Often, the revenue/cost is displaced — as when Google doesn’t charge for its search engine (et. al.) but of course makes money from ads. We don’t get charged for TV content usually (though we may be charged for distribution of TV signals); that too is paid for by ads. And those ads cost us money in increased product prices. Maybe the networks will end up free and unlimited bandwidth but we’ll have to watch ads? Hmm.
In any case, I don’t really see that most things can be free. If I understand Anderson correctly, information will be increasingly free — that may be true, but accessing that information won’t be.
However, i do think it’s worth asking big questions like this. While networks may not be free now, they are a whole lot cheaper — and that HAS changed how we design things. If you can detect the trends toward lower cost (or greater abundance) — in IT resources like networks, or business resources like staff or product components — you can change your architecture and your enterprise (your enterprise architecture!) to take advantage of those changes in cost, and deliver signficantly new options to the business. Clearly the Internet — a low cost, high bandwidth network widely available — and Web technology (HTTP/HTML, basically) is a case of where this trend was capitalized on (say by Amazon in becoming a different kind of book store than the bricks and mortar Barnes & Noble). So, the experiment of imagining free or just much lower cost resources that your current business depends on is a good one. These discontinuities can lead to major business change.
Of course knowing when things will get more expensive (greater scarcity) is ALSO a useful trend to watch and take advantage of. Free (or just way cheaper) is not the only cost trend to watch. Moreover, something (like fuel costs) that is widely variable in cost is yet another thing to be aware of (as airlines have learned, but still find it hard to master).
Thus, while architecting “free” is a great idea, it’s not the only magical thinking that will provide value. Learning about what things actually cost now and what they might cost in the future — close to free, free, or nowhere near free — must guide architecture thinking.
Feel free to use this advice when you architect.
Category: EA Tags: EA
by Bruce Robertson | July 3, 2009 | 20 Comments
To quote from my Gartner colleague Lydia Leong’s recent post on cloud computing: “Capacity planning equals budget planning, so it’s rarely an, “eh, because we can scale quickly, it doesn’t matter.”
I read this three times before it sunk in. Capacity = budget? Yes!
We’ve often in our Gartner EA practice discussed that EA should focus on service levels beyond just RAS (reliability, availability, scalability) into other “-ilities” like securability or interoperability, and even affordability (cost as an attribute of the system or solution, stated so that like other attributes higher is better). This is not however common practice. Mostly we plan the best (ie most RAS) solution, and then just tell the customer what the cost is.
But, perhaps the balancing of cost and RAS (or just performance or capacity) will become more common over time as cloud computing services change how we compute value for alternative architectures. Within the most elastic of cloud services, the elasticity of provisioned service is directly exposed to the customer, both for performance and price. Both go up and down — this is what elastic scalability means. Scalability alone connotes ONLY scaling up, never down again.
Furthermore, as capacity goes up (or volume of usage, anyway), the overall cost ALSO GOES UP. This is why contracts, as Lydia so clearly points out, will move from simplistic usage only to all sorts of capped and other forms — look at your mobile phone bill for a model, for example.
Thus, as capacity is planned, the budget is also planned. More to the point, as capacity is actually used, costs go up. Not paying for not using capacity means paying for using it. (I had to read my own sentence twice to make sure — yes, it’s true!) The problem will move from overpaying for unused capacity to overpaying for used capacity (at a higher rate — like that mobile phone bill). Which means we’ll be right back to paying for average capacity (and generally not actually using all of it) to get more predictability in budget.
It also means that EA teams should stop saying that they’ll design a solution (or even more general guidelines for solutions to repeat) for high scalability becuase that’s best. It means we need to design to fit a budget, and that we’ll need bronze rather than platinum configurations. Perhaps we can design a system that can do both service levels simultaneously, but I’m skeptical on this. It seems possible in theory — and cloud computing is a new way to try for this kind of perfectly scalable solution — but hard to deliver in practice. Even on the cloud, we’ll have some service providers that can scale higher but will cost more, while others opt for lower cost without the same global scale. And, we customers will have to CHOOSE between them. In fact, we’ll probably offer a variety of such choices to our customers, mixed in with ones we provide (versus sourcing from cloud or other outsourcing vendors).
More importantly, however, this can be used to manage demand, not just to design the supply. Customers using elastic services will decide how much to use based on budget. They will in some cases say we’ll just say no to scaling up capacity, because we can’t afford it! The assumption that more is better (upsizing) will yield to the idea of right-sizing — just enough and of course just in time.
Category: EA IT Governance Strategic Planning Tags: cloud computing, EA
by Bruce Robertson | July 2, 2009 | 7 Comments
Defining EA as a set of services are a new way to describe what EA does and what the outcome or result or deliverable of EA activity will be. Using the service term certainly gets a useful clarifying discussion going about who the consumer and provider are, and what is provided by the provider to the consumer. This is a fresh way to think through what EA is (particularly if you ask some of your EA consumers to participate in the definition exercise!), rather than just describing it as a set of processes.
Gartner’s starter kit for EA Services (Gartner clients can read about this more here: http://www.gartner.com/DisplayDocument?id=757437) starts with these 5:
- EA Creation
- EA Consulting
- EA Compliance
- EA Communication
- EA Research
Other people I’ve talked with this about like these but suggest adding Lab and Reporting to this list. But, if you have too many, you’ve defeated the purpose! Maybe indeed 5 is a realistic limit to the base list.
The simplest attributes or metadata I’ve started with in planning these are these attributes (which I have in a table in the note referenced above):
- name (including alternate names)
- description
- deliverables
- EA team roles
- SME roles (subject matter experts — EA people do not alone provide all the horsepower)
Basically, this is: what do I get (consumer) and what do I do and produce (provider). I do actually find the consumer / provider thinking VERY useful in making things clearer to key stakeholders. This is what makes many clients move from just a process view of EA to a service view of EA.
In discussing this with clients, I’ve found many that are thinking the same way. For example, Todd Biske here: http://www.biske.com/blog/?p=653. He’s also suggested (http://www.biske.com/blog/?p=655) an addition to the attribute list: trigger. Some EA services are provided on request (consulting), while others are provided on a more event oriented (and not by human request) way: scheduled refreshes and/or process calls. Maybe though, all of these are events (requests) of one kind or another — some human (PM requests EA consulting), some machine (all the new projects have been documented, so get them into the EA repository), some long running repeated requests (CIO: give us these reports regularly), some immediate (CIO: tell me about why we need EA again?). So, is this a good add to the EA service attribute list?
What are your EA Services?
Category: EA Tags: "EA Services"
by Bruce Robertson | May 8, 2009 | 19 Comments
Lately, news in my feed reader (Google), people/entities I follow on Twitter (Twitterfon), and even good old paper newspapers (NY Times, Washington Post) seem to be doing more with trends. You can get trends on Twitter search terms (http://www.twitscoop.com/), trends on searches on Google (http://www.google.com/trends), even trends on American Idol futures. Gartner’s own web site shows trends too, for example the Gartner EA peer search trends (cloud computing is large in our search cloud as I write this). (Disclaimer: you do have to be a Gartner seat holder to see this peer search trends info.)
It is worth noting that some of these are single moment trends (a snapshot in time of many search terms = what’s hot now) while others are trends across time (of fewer search terms, then). Both views are interesting.
But searching for trends in EA terms can be misleading. I just tried Google trends on the FEA reference model acronyms (PRM, BRM, SRM, DRM, TRM) and of course some of these acronyms are NOT just for FEA (most notably DRM, which also means digital rights management). That doesn’t help.
How can one track EA trends, then? On Google, the trend for searches on the term EA has remained pretty constant over the years — constantly declining, which itself is interesting. As an ongoing discipline, it has passed the hype phase (try trending EA against cloud computing, for example). We’re in the plateau of productivity, using Gartner Hype Cycle terms. But, consistency does say something, even if declining — it’s not spikey. It’s not new. Perhaps this should just make all of us EA people feel old?
In some sense, this constant nature of EA searching may tell us something. It may imply some sense of maturity. Indeed, many now seem to understand what EA is, at least to some extent. There is confusion of course — about scope, models, value and many other things — but the term is not going away and the discipline isn’t either. Granted, the people may change, but even in these tough economic times we haven’t seen a huge push to just stop EA work altogether. Maybe this constant level is enough for now.
Still, it should worry us that it seems to be declining. Maybe this is just that searches are declining, but other metrics (like attendance at EA conferences, etc.) are up. The more mature, the less searching? Only newbies search? Hmm. Not sure this really means much.
How about I leave the “trend for trends” topic by suggesting instead that EA practitioners look at trends, specifically trends in EA value delivery. Many will push hard for metrics to describe most importantly how EA provides a valueable service to the business. But, let’s not forget to show trends in those KPIs — how a given KPI’s measurement has changed over time. Metrics are often best used for not just the snapshot in time, but the longer term over many years trends. We want to show that EA is increasingly delivering a valuable service to the enterprise, even if the search term shows a consistent decline. We’d like our value trends to go up! So, if you have good stories for using such KPIs over time, do tell.
==========================================================
On a side note: to see who at Gartner is blogging on “enterprise architecture,” try this google search: enterprise architecture site:blogs.gartner.com
Category: EA Strategic Planning Tags: EA, metrics, value
by Bruce Robertson | April 29, 2009 | 2 Comments
While Google’s App Engine is basically free for users (up to quota limits), it has significant constraints in development languages supported (Python and soon Java) and indeed requires writing code. Amazon Web Services do not require specific languages and can even run existing applications (there are limitations of course). But, you have to pay.
Until now. Amazon is offering free service usage to education customers for teaching and research. See http://aws.amazon.com/education/ for more detail. In truth, it’s not actually free — it’s just a grant for up to $100 per teacher or student.
In my opinion, this is a smart move for Amazon, as it has been for Google to offer free service (and in Google’s case: not limited to education). It should generate a larger set of future paying users / developers trained on using AWS services, building demand. Over time, enterprises will hire (or educate) more developers on using cloud services like Amazon’s. And, as usual with other product lines, vendors who hook you in school can win your business when you go to work. This should also generate more case examples of real projects running on top of the services. With education under budget pressure itself, this should be attractive. In fact, Amazon’s site notes that Maryland and Harvard already have courses designed to teach cloud computing using AWS services.
Now that things are free, I’d expect to see more.
Category: EA Tags: Amazon, cloud computing
by Bruce Robertson | April 26, 2009 | 22 Comments
I was enjoying a shady Sunday morning patio chair and catching up on things Twitter and just being virtually social. (My Twitter is brucemr in case you care to follow.)
The latest version of Tweetdeck has enhancements that are nice, including Twitscoop support and more URL shortening services like Digg’s. In fact, here’s Tweetdeck’s blog post basically bemoaning the fact that there are actually too many to support. They note they already support these five: bit.ly, is.gd, tinyurl.com, tr.im, and twurl.nl. I guess you’d say this is their short list of shortening services.
Shortening services, outside the kitchen anyway, make a long URL short. (Duh!) Sometimes a long URL will not be clickable after posting or emailing, as word wrapping messes things up. Most critically, however, these things are needed for Twitter — where 140 characters makes space a premium. TinyURL.com is the first I remember. Oddly, the tinyurl of TinyURL.com is longer than TinyURL.com: http://tinyurl.com/bcvnvt.
Some already say these shortening services make it too easy to link to things bad. You can’t see the actual URL before being redirected and frankly do you trust these service providers to even do that safely? I guess we do. Such obfuscation has it uses for the providers too, as TinyURL.com suggests for affiliate URLs.
However, others think of other opportunities — see ZDnet’s David Berlind’s blog post which suggests that “TinyURL is the next YouTube” and worries that it’s value as a “demand intercepting weapon” and “stealth intention engine” will mean more not less use by advertizers. Berlind even thinks TinyURL.com’s developer Kevin Gilbertson is unaware of the opportunity to leverage his own data for advertising gain (well: he sells ads on his actual web page, but I can’t tell if these matter when using a Twitter client like Tweetdeck to front end the service). Berlind also blogged on another problem with intermediary services like this: Yesterday, Slashdot asked ‘What if TinyURL goes down?’ Today, it’s down (and it hurts).
So, what do we really know about these players? Really. Not much. At least, that’s the short answer.
The long answer is: we really don’t know much about them, but there sure are a lot of them. More every day. And, like all things we use, we need to know more. Wish I had the time to take a longer view, but I don’t.
The patio now suggests it’s time for socializing in the real world. Later.
Category: Fun Tags: Fun, social software, Twitter
by Bruce Robertson | April 24, 2009 | 594 Comments
One goal, but I hope never the only goal, of Enterprise Architecture (EA) is to help understand and manage and indeed improve the value of IT spend. Many techniques are employed, including tying EA strategic requirements to project portfolio decision making, planning lower cost alternatives, and many others.
However, one technique that is now visible online for all of us to view is the US Federal Government’s Office of Management and Budget (OMB) consolidation of agency EA reports. OMB has been collecting EA data from the agencies for a while now, and along with the common EA content (process, information, applications, infrastructure, etc.) mapped to the FEA reference models (PRM, BRM, SRM, DRM, TRM), they have also collected spend info in these categories.
OMB is very interested in the money — and see’s EA as a way to control spend better than before. Basically: have a plan to spend, then spend according to the plan. EA is a big part of the basic “architect, invest, implement” mantra I hear at the Chief Architect Forum (CAF) meetings I get to attend locally here in the Washington DC area.
Now this data has been collected and represented in a way that we can all see how the spend in IT is allocated to the FEA BRM (business reference model) categories:
VUE-IT (Visualization to Understand Expenditures in Information Technology)
For example, you can see how much each of 11 agencies spent (2008) and plans to spend (2009) on “Disaster Preparedness and Planning” and that DHS is spending 81% of the total ($178M). You can continue to drill down into how the Dept of Interior is spending their 2% to see that it comes from 3 bureaus, that one (National Park Service) is spending on fire effects monitoring databases, and from there you can call up the Dept of Interior OMB-300 and see more detail on the IQCS application.
This certainly is visibility and transparency of spending info. We can all view it in VUE-IT.
While I wanted to make sure to highlight this new public approach to EA, I also wanted to ask some questions:
- Is this something you CAN do in your enterprise? I bet not.
- Is this something you WANT to do in your enterprise? I bet some of your stakeholders would like this (CFO, for example).
- What would it take for you to do this? Lots of new work, EA tools, etc. at least.
But, mostly, I’d like to see you answer this question: Is this a critically important thing for EA to do?
Category: EA Tags: EA, EA, EA Example, FEA, Federal Enterprise Architecture, OMB-300, VUE-IT
by Bruce Robertson | April 21, 2009 | 19 Comments
I’m now blogging on the Gartner Blog Network (GBN). Everyone else blogging at Gartner is here too.
To get started, I suppose it’s good to set a few goals for my efforts. Among the things I’d really like to do are these:
- Link to interesting EA content available online — to help those who don’t look around as much as I do
- Highlight EA approaches that are different — good and bad, IMHO (note: Gartner’s official opinions will published as normal — my comments here will not be official Gartner positions, but I’ll refer those who are clients to such material as a courtesy).
- Have some fun — life in EA shouldn’t be boring or drudgery
I’ll let these goals for my efforts inspire me and see where I go with it. I hope those who read will comment to make things even more interesting. Thanks.
Category: EA Fun Tags: EA, EA
