As the scope and focus of enterprise architecture has evolved during the past 15 years, your role as architect has shifted from tactical IT decisions to analysis and linkage to the business strategy. The Enterprise Architecture blog will help you keep abreast of this shift, with comments and insight from the EA team plus tips on the latest Gartner research. Use the blog to offer comments and questions, and let us know what you're thinking.
- 01 April, 2008 06:32 PM EST
- Poll On EA Budgets: No Big Surprises
- Posted By: Robert Handler, Research VP
We recently polled you to see if there were any big changes to your EA budgets in light of the current economic turbulence. What we found is that most of you are reporting their EA budgets to be the same as, or larger than, they were the prior year. Overall, 37% were the same as last year. 36% reported increases. 27% reported decreases, with only about 9% of those reporting much lower EA budgets this year. Given the ever changing conditions, however, we will continue to monitor and report any changes.
- 10 March, 2008 06:15 PM EST
- Coming Up - Gartner Emerging Trends Symposium/ITxpo
- Posted By: Robert Handler, Research VP
In just a few weeks, Gartner will host one of the industry's most exciting, must-attend events - Gartner Emerging Trends Symposium/ITxpo. This annual event unveils our three- to five-year technology and trends outlook. Many of our leading EA analysts - including Betsy Burton, Anne Lapkin, David Newman, Bruce Robertson, Bill Rosser and me - will gather to dive deeply into hot topics like crafting emergent architectures, open source software in the enterprise, managed technology diversity, cloud computing, software (and increasingly everything) as a service, virtualization, bridging EA to the business, and more. We'll answer questions that have been burning in your mind when you meet with us face to face in one-on-one appointments.
For a full view of the EA content of the event, have a look at the recommended agenda we've created for Enterprise Architecture and Planning Leaders. In addition to all this great content, joining the Enterprise Architecture Symposium Community will provide you the opportunity to quickly find peers focused in your area and begin connecting on the topics most important to you. Dont miss this opportunity to be part of an unparalleled experience April 6-10 in Las Vegas. Once you've registered for the event and signed up for your Symposium Community, join the Enterprise Architecture Community Pre-Conference call with Anne Lapkin on Thursday, March 27 at 2 pm EST. Hope to see you in Las Vegas!
Agenda for Enterprise Architecture Leaders
- 05 February, 2008 06:42 PM EST
- Charles (My Son) the Architect Succeeding
- Posted By: Robert Handler, Research VP
Maybe it was turning six in December that did it? I dont think so. Out of the blue, my son, the Lego fanatic, has busted the learning curve. He can now assemble things well beyond his age, assuming the accuracy of the suggested age limits on the toy box. He enthusiastically brings me into his room to show me his latest creation generally something he talked his mother into buying that, in theory, is well above his capabilities. So, what happened? Was there a tipping point? A point when he just "got" how to do it, regardless of age appropriateness? I posit this to be the case.
I also posit that the Lego analogy is sound. I also posit that the approach to modular architecture must be coupled with appropriate and effective training, coaching and mentoring. If that is done properly, then eventually a tipping point will occur. Now, if I can just get him enthused about house chores . . .
- 15 January, 2008 10:50 AM EST
- Consumer Gadgets and IT
- Posted By: Robert Handler, Research VP
In a previous poll, we asked you, What is your favorite consumer IT gadget? Here were the results:
MP3 player: 37.9%
GPS: 17.2%
Home entertainment equipment: 25.9%
Wireless device: 13.8%
Other: 5.2%
Today, a news article entitled "Personal Devices Create a Dilemma for Corporate IT" came out that served as a literary "straight man" leading into why we asked the question in the first place. We knew that many would receive these (or buy them themselves) over the holidays, and you would have to deal with them now. I personally have all of the aforementioned, except the home entertainment system (I had an inexpensive home entertainment system, but my wife said the only acceptable volume level was 0), so I gave it away.
It might be a worthwhile exercise to ensure that these devices are addressed in your technical architecture appropriately. Many want to simply prohibit them, however, I can assure you that the most senior executives will come in with the most advanced gadgets and request that they work with internal systems. Unless you can get them to agree that attaching these devices to the corporate network is a bad idea, fighting the trend could erode support for EA. Think it through. Oh, and Happy New Year!!!!
- 27 December, 2007 03:16 PM EST
- Confessions of an EA Analyst
- Posted By: Robert Handler, Research VP
It's almost the new year and I swore off New Year's resolutions a few years ago with a resolution for no more resolutions. That said, I know the start of a new year is when people like to come clean and start fresh. Generally, this time of year people celebrate, often to excess, and then promise at the start of the new year to do things differently. I'm going to lose weight
I'm going to exercise . . . I'm going to . . . whatever. It is in that spirit that I'm going to come clean.
On occasion, one will ask, "Does Gartner do enterprise architecture?" or "Does Gartner have an enterprise architecture?" Someone even asked in a recent comment that became a blog entry. The answer is yes. It probably looks about like yours does. It's not perfect. There are parts that are incomplete. There are parts I don't care about. I couldn't care less about our standard for accounting software. I care that whatever we use for payroll works. I care that whatever we use for expense reimbursement works. Most of it is noise, except the standards and principles around the IT Leaders site.
I'm responsible for getting new things on that site. My brain sometimes comes up with crazy ideas that seem to make sense (for example, online maturity assessments or a battery of templates for a fictitious company). These are things that are new. They aren't in the standards. Sometimes I need to get approval from a committee. Sometimes, I resort to creative use of standards to build things for which they might not have been intended for. Sometimes . . . well in the interest of keeping my job, I'll stop confessing and get to the point.
Although I'm considered an expert in enterprise architecture, write about the topic and even train people in the topic, I'm no longer acting as an enterprise architect. That's someone else's job. Im on the business side of things, believe it or not. It so happens that our business is IT, so the distinction often gets blurred. Nonetheless, I'm business, we have IT, we have an enterprise architecture and sometimes it's a pain! Thats right, a pain. I want to do new things that make sense. Sometimes you ask for them. I may be trying to implement your ideas in response to your requests when Im stopped by our "enterprise architects." So, while I know enterprise architecture makes sense, and I've done amazing things with it in practice, at present, it's a royal pain (I can't say where again, in the interest of keeping my job).
Why on earth would I share this? Well, it's for one simple reason: I'm willing to bet that in your organization, there are folks who see enterprise architecture as a royal pain in the you-know-where. I'm willing to bet you know who they are. I'm willing to bet they are frustrated, and possibly for good reason. Therefore, here's my proposal: Take our recommendation of being "enterprise architecture minimalists" to heart. Get innovators involved in the creation process. Make the process of vetting exceptions and variance requests extremely expeditious and arm that process with decision criteria that really matter. Do cost-benefit analysis. If you are going to do New Year's resolutions, then resolve to walk a mile in the moccasins of your key stakeholders next year. Make enterprise architecture a positive and empowering experience.
Oh, and happy new year!
- 18 December, 2007 06:25 PM EST
- A Hiccup With the Lego Analogy to Enterprise Architecture
- Posted By: Robert Handler, Research VP
Many of us use Legos as an analogy to espouse the virtues of standards and modularity. True, amazing things can be done with a basic set of Legos. They are easy to put together, easy to change and even easy to store. If we could architect our organizations out of simple building blocks, then we'd get the same aforementioned benefits our children do with their Lego toys, right?
It just so happens that I have a five-year-old son named Charles. Charles loves Legos. Well, he doesn't really love Legos, he loves structures built from Legos. When he was younger, the rectangular blocks sufficed. As he got older, however, he became enamored with the more complex Lego kits. (In case you didn't know, they have kits that are in the shape of castles, space ships and other interesting things once assembled.) These kits are usually targeted for children ages seven and above. Charles, however, is only 5. He's very bright and very tenacious. Somehow he manages to convince family members, other than me, to purchase these sets for him. Being that his birthday is in December, we get a double whammy this month. We receive lots of Lego kits designed for children seven years old and above for the holidays and his birthday.
Charles doesn't really like putting the Legos together. He likes the end product. To him, it's something between a toy and art. Enter dad (me). I get the "pleasure" of helping Charles put these kits together. Why is "pleasure" in quotes you might ask? Usually he wants to put the kits together right before I am supposed to go on a business trip or right before he's supposed to go to bed. Sometimes he's gotten them started already. Given his age and the targeted age for the product, he does a pretty good job. He can get the kits to about 80% complete. Then dad (me) has to finish them.
Now, as a child, my brother enjoyed doing things like that. I didn't. And I certainly don't enjoy doing it as an adult, especially if it's late at night or right before I'm to leave for a business trip. Because of the political ramifications of not completing his projects, however, I usually end up doing them. Sometimes it's 20 minutes of taking it from step 18 to step 27. Sometimes, however, a mistake was made early on (for example, in step 4), and I have to trace it backwards. It can take an hour or two to deconstruct and then reconstruct and complete his project (designed for the pleasure of a seven year old).
What's the point? Well, we talk about Legos as an analogy for how simple things can be if we modularize and use standards in IT and business. The fact is, like my son Charles, the business probably doesn't care that much about those details. It wants the completed item. If we cannot deliver within its desired time frame, then it may start over again like my son Charles. If the business gets into trouble, we may have to bail it out, like I do with Charles. True, it would be much harder if Charles chose good, old-fashioned models that required real glue and were unforgiving of errors, but it's still a lot of work, even with standards and modules especially the highly specialized modules (such as a Lego castle door hinge).
The enterprise architecture lessons I learned from my son, with a little help from Lego, were:
1. When someone in your organization wants something, they want it when they want it, so be prepared to deliver quickly on whatever they want.
2. They often don't care how they get what they want, so espousing the virtues of concepts pails in comparison to the delivery of what they want (and good expectations management).
3. If pressed, to get what they want, they'll look to alternative channels or try to do it themselves. Be prepared for this reality.
4. You may have to bail out folks who took on more than they were capable of doing, and that's just life. Be prepared for this reality too.
5. Standardization and modularity may help ease the pain of construction (or change), however, it's still painful and it's still work. Know how to manage change pain.
6. Not everything can be built from simple standardized modules sometimes you need specialized, single-purpose modules that can hook into the overall system via standards, and that's OK.
7. Never underestimate something seemingly simple, even if the experts say it can be constructed by a seven year old.
- 03 December, 2007 03:26 PM EST
- Happy New Year?
- Posted By: Robert Handler, Research VP
We had an interesting poll that ran longer than usual. It had to do with growth expectations. The interesting thing about it is how things changed so dramatically. At the beginning of 2007, we surveyed clients and non-clients. We discovered that most expected modest growth. One of the most popular tactics to attain this growth appeared to be increasing revenue from existing customers by strengthening customer relationships. Many also expected to use performance improvement initiatives to drive efficiencies.
Here's what we found in the December 2006 to January 2007 time frame:
16.2% expect substantial growth in revenue/profits
50.5% expect modest growth
27.6% expect modest decline
4.9% expect substantial decline
0.8% expect revenue/profits to remain stable
This thinking seemed to carry for quite some time. On 17 September, we pulled interim results. Here's what we found:
25.7% expect substantial growth in revenue/profits
53.7% expect modest growth
9.6% expect modest decline
2.9% expect substantial decline
8.1% expect revenue/profits to remain stable
You can see the change in sentiment; however, the majority still expect modest growth in the next 12 months. If you look at the results now, however, you see the following:
25.1% expect substantial growth in revenue/profits
52.1% expect modest growth
10.6% expect modest decline
2.5% expect substantial decline
9.7% expect revenue/profits to remain stable
Many argue that the economy is driven, to a large extent, by expectations. So, although the percent of participants who expect modest growth really hasn't changed that much, the number who expect substantial growth in revenue/profits to grow has increased, and the number of those who expect revenue/profits to remain stable has increased as well. The only thing that appears to have dropped is those who expect substantial to modest decline.
What does this mean? Not much. It provides another data point to help gauge the economic climate. That being said, when I first started as an IT analysts some eight years ago, I was asked to present at a business conference. I chose to present on "Managing IT During Tough Times." I presented, predicting a recession. Directly after my presentation, an economist from The Conference Board who claimed to have worked for Alan Greenspan suggested I was wrong, stating we would "narrowly miss a recession and enjoy sustainable growth." That was at the end of 2000. I was right. He was wrong. Regardless of how you think the economy will play out, you have about a 50% chance of being right.
As 2007 winds to a close, at this point, 2008 only promises uncertainty for most of us. Bear in mind, however, that uncertainty brings opportunity. There are countless instances of companies who seized opportunities during uncertain times. Focus on the opportunities inherent in the uncertainty. Oh, and happy holidays.
- 23 July, 2007 11:28 AM EST
- Average Enterprise Architecture Program Maturity Levels By Industry
- Posted By: Robert Handler, Research VP
For anyone who has taken the Enterprise Architecture Program Maturity Self-assessment, you've probably noticed your results compared with your industry. For the record, the industry number is not dynamically updated in the database; it's updated quarterly. This allows us to validate the data that goes into your average and ensure that it represents your industry. We've found significant differences by industry, with the highest being "IT Service Providers" at 3.2.
Enterprise architecture program maturity should be reviewed periodically annually at a minimum. This will provide insight into issues and opportunities. It also serves as a great data point for demonstrating progress. If you haven't done the assessment in awhile (or at all), it's definitely worth the time.
- 18 July, 2007 07:00 PM EST
- The Best Enterprise Architects I Know Don't Work Too Hard
- Posted By: Brian Burke, Research
Recently, we debated an enterprise architecture (EA) maxim: "First speed, then breadth, then depth." The crux of the debate: Should breadth really precede depth? Or is it better to dive deeply into a focused area of the architecture where EA can deliver key benefits before building out across EA perspectives in a shallow fashion?
We all agreed that "speed first" was the most important part of the maxim. Despite our differences concerning some of the nuances surrounding the best way to achieve that speed whether by limiting breadth initially or by limiting depth we concluded that "just enough architecture, just in time" (JEAJIT) was the maxim that really mattered.
Among the best routes to JEAJIT is project-driven (as opposed to project-focused) EA. More often than not, it is highly beneficial to let critical, high-profile projects drive out EA deliverables especially in all-too-common situation where high EA expectations are accompanied by relatively low EA staffing levels.
As an illustration of the benefits of project-driven approach and the struggle that arriving at the "just enough" part of JEAJIT can entail the following outlines some typical exchanges between a Gartner EA analyst and a client engaged in a new EA effort.
The Advice: Get the EA charter done.
The Client Reaction: Much pain and consternation goes into trying to create an EA charter.
Advice: Download the sample charter, delete all the contentious portions and edit the rest.
Client Reaction: This gets done in three days.
Advice: Get the common requirements vision (CRV) done.
Client Reaction: Much pain and consternation goes into trying to get perfect information about long-term strategies where such information doesnt exist.
Advice: Go with what is obvious and well-known for example, "start with the project backlog."
Client Reaction: This gets done in three weeks.
Advice: Start with technology standards, since this is an area over which they have some control.
Client Reaction: Much pain and consternation goes into trying to select the perfect technologies in each domain.
Advice: Identify technology owners, take a quick inventory of what they have today and classify each technology in terms of its life cycle position (for example, prototype, preferred, supported, unsupported or decommissioned).
Client Reaction: This gets done in three months.
Advice: Create technology patterns.
Client Reaction: Much pain and consternation goes into trying to identify the perfect components and interfaces to populate the first pattern: n-tier client/server.
Advice: Look at the recent n-tier client/server development projects, select one as exemplary and create the pattern using the same components.
Client Reaction: This gets done in one month.
Advice: Start to fill out the other patterns needed to meet the requirements identified in the CRV.
Client Reaction: Much pain and consternation results when new patterns that havent been done before in the enterprise are required.
Advice: "Deputize" project design teams that are already addressing new requirements to develop the new patterns while the EA team provides close oversight to ensure that each new pattern is extensible and can be applied generally for future projects.
Client Reaction: This gets done JEAJIT, since the real work is project-driven and project-funded.
And on it goes.
The root cause of many of these problems is that enterprise architects often have introverted/intuitive/thinking/judging personality types (under the Myers-Briggs classification scheme) and are, therefore, constantly striving for perfection. Focusing on JEAJIT and project-driven EA helps overcome this tendency by keeping the focus, first and foremost, on the fast and easy, rather than the broad or the deep.
- 19 June, 2007 04:46 PM EST
- Communication Resources in Enterprise Architecture Teams
- Posted By: Robert Handler, Research VP
In a recent poll, we asked: What percentage of your enterprise architecture (EA) team's nonarchitect support staff is dedicated to people issues (such as communications and change management)? Here are the results:
Greater than 20% --- 16.7%
15% to 20% --- 15.4%
10% to 15% --- 18.6%
5% to 10% --- 19.9%
Less than 5% --- 29.5%
This survey was based on 207 clients and nonclients throughout Europe and North America, performed between December 2006 and January 2007. In this survey, on average, approximately 13% of EA staff is devoted to communications. Thus, the poll results are relatively consistent with a formally executed survey.
This number, however, may be far too low. The most statistically significant dimension of architecture maturity appears to be stakeholder sponsorship and support. What that means is that the most mature, and probably most successful, EA efforts focus heavily on building and maintaining support for EA, and fostering communication with and between stakeholders.
Although this is a wonderful validation of common practice, determine whether you have the appropriate communication skills in your EA team. Look beyond common practices toward exemplar communications to drive EA excellence.
- 01 May, 2007 10:28 AM EST
- Enterprise Personality Profile
- Posted By: Robert Handler, Research VP
You may have noticed a new interactive tool in the enterprise architecture Gartner for IT Leaders Toolkit "Business Issues for EA and Your Enterprise Personality Assessment." We used data from the maturity assessment, along with data from surveys conducted in 2006, to identify critical issues in 2007. We then used a proven diagnostic tool, the Enterprise Personality Profile, to structure guidance on these critical issues in our new tool. If you spend 15 to 25 minutes completing your Enterprise Personality Profile, then you will receive a 12-page report that provides guidelines on how each of the key issues for enterprise architecture in 2007 is typically, and successfully, addressed in similar organizations.
Please note that although this guidance is fairly accurate and appropriate, every organization has nuances and idiosyncrasies that cannot be identified programmatically. If the guidance from this tool defies common sense, then defer to common sense. If you have questions on the guidance, then please schedule an inquiry with an analyst. We hope you find this tool useful and insightful.
- 01 May, 2007 10:27 AM EST
- Bank XYZ
- Posted By: Robert Handler, Research VP
For many years, my colleagues and I have been asked by clients for a sample enterprise architecture. At the end of 2006, we ran out of excuses and decided to create one. It is not the perfect enterprise architecture, however. Those who follow our research will know that we don't believe there is such a thing as "a perfect enterprise architecture." Our mantra, with respect to enterprise architecture, has always been "just enough, just in time."
We have, therefore, created an enterprise architecture for a fictitious company, Bank XYZ, along with background information for that company, so you can see a realistic enterprise architecture in context. It was created in bite-size chunks (that is, 57 files) to enable easier retrieval. We've also included information on the purpose and intended audience. We hope you find it useful and insightful.
- 25 April, 2007 02:13 PM EST
- Enterprise Architects Take Heed: IT Innovation Has Returned to Center Stage
- Posted By: Ned Frey, Senior Writer
How can enterprise architecture (EA) support and enable technology innovation? That was one key topic of a talk given by Gartner analysts Robert Handler and Brian Burke Tuesday at Gartner's Spring Symposium in San Francisco. The presentation, "Enterprise Architecture 2012: State Shifts and Stratagems," examined trends that will shape the context for EA in next three to five years and IT innovation was chief among them.
"After years in the wilderness, technology innovation is once again taking center stage as a business focus," Handler noted. In light of this resurrection, he added, EA is in the ideal position to understand and communicate the impact of technology change for the business.
One implication of this trend is that competitive technology intelligence will become increasingly critical competence for the business. "Disruptive technologies remain the primary game changers for industries," Handler said. "Your most dangerous competitor won't be the company that (just) installs SAP to cut costs by 10%."
So what does this trend mean for EA specifically? For one thing, architectures will need to be able to support innovation by putting fewer constraints on the business. "Less is more," Burke noted. Rather than producing binders full of rigid specifications, EA teams need focus on defining a minimal set of constraints in the middle of the architecture to achieve organizational agility at both ends. Burke added that architects who want to support innovative environments should embrace the Chinese concept of Wu Wei, or "build to grow" that is, create an engine of continuous transformation.
During the Q&A session at the end of the presentation, one attendee asked for tips on how to discover what technology innovations his competitors were engaging in. Handlers answer? Read your competitors' job postings for IT positions. "This can reveal a lot about what they're trying to do with technology." Handler also suggested performing Web searches for news stories on these companies to glean any info they may have revealed to reporters about what theyre up to. Burke added another tip: Listen in on the earnings calls of your competitors. Youd be amazed how much companies sometimes reveal to investors.
- 20 April, 2007 03:34 PM EST
- Socializing Technology at Symposium
- Posted By: Robert Handler, Research VP
Look at recent news. Google is buying a video conferencing company and Oracle is stepping up its content management offerings (more on that can be found here). If I didn't know any better, I might say relational databases and transaction processing were going the way of the dinosaur. Don't worry, they are not. These data points do, however, support one of our major trends - Socializing Technology. The focus of IT will shift from computing and calculation to communication and collaboration. If you haven't factored this into your enterprise architecture, you probably should. And, if you're attending Symposium/ITxpo in San Francisco, be sure to check out some or all of the presentations on the Socializing Technology track at the conference, one of eight we'll be discussing in detail.
- 09 March, 2007 07:02 PM EST
- Communication Is Key
- Posted By: Robert Handler, Research VP
Here are the results from our recent enterprise architecture (EA) poll. Respondents (n=83) were asked, "How much of your EA effort is devoted to communications to various stakeholders?"
None: 11.8%
15% or less: 44.7%
15% to 25%: 20%
25% to 50%: 23.5%
We are consistently being told by successful practitioners that 50% of their time is spent on communications, but it's not enough. These results lead me to believe that either we have a bug in our polling software, which is doubtful, that the poll was answered without much thought or that we had better have some discussions with the respondents who selected 15% or less.
In addition to this poll, however, we completed a major surveying effort in the fourth quarter of 2006. We asked 250 participants to determine how much of their effort is expended in each phase of the activity cycle, including "communicate." The average percent of effort spent on communication for this group was 16%. This, by the way, is not a best practice; it's common practice.
If you answered "15% or less" or "None," unless you were joking, please contact us.
- 06 February, 2007 10:13 AM EST
- More Enterprise Architecture Survey Data: Still Digging
- Posted By: Robert Handler, Research VP
While digging through our enterprise architecture (EA) data, I stumbled across some information that I found interesting. We asked more than 200 EA teams what types of architects they had; here was the breakdown:
Chief Architects 12%
Solution Architects 13%
Business Architects 12%
Technical Architects 23%
Information Architects 14%
Service Architects 9%
Project Architects 13%
Other 4%
From the maturity study, we discovered that the average number of full-time equivalents supporting EA was 2.2% of IT headcount. This means that there are a lot of architects of varying types floating around organizations.
The top five drivers for EA in order and ranked on a scale of 1 to 5, with 5 being the highest were:
Business/IT alignment (3.9)
Reduce technology cost (3.84)
Reduce project or service redundancy (3.66)
Technical adaptability (3.65)
Service-oriented architecture (3.61)
This information is fairly interesting by itself, but taking it in context is even more interesting. Forty-five percent of EA staff is made up of architects (of various types), and 33% is support staff (of various types), including 21% project managers, 19% administrative and 16% facilitation staff. If the top goal for EA is "business/IT alignment," then one would expect to find the staffing heavy with business architects, facilitators and change management specialists. The actual makeup, however, is heavy on technical architects and project architects, which leads us to believe that one or more of the following is the case:
EA teams are working on simultaneous goals in parallel, with more important goals being less resource-intensive.
Work streams required to meet EA goals are not exclusive to the goals.
"Business/IT alignment," as a goal, is being superseded by "reduce technology cost" and "technical adaptability."
EA teams are not doing well at matching staffing requirements to goals.
This information is still preliminary. More to follow
- 01 February, 2007 01:09 PM EST
- Activity Cycle Effort
- Posted By: Robert Handler, Research VP
We are currently in the process of analyzing data from 2006. One of the things we were curious about was the distribution of effort over the phases of the activity cycle that is, what percentage of an enterprise architecture (EA) team's time is spent in each major component. Our sample size of 250 EA teams shows the following:
Communicate 16%
Strategize 24%
Architect 27%
Lead 18%
Govern 15%
Many of our clients say they spend 40% of their time communicating but it isn't enough. So, what can we make of this data? How can we use it? First, it's important to note that this is not a best practice, it's a common practice. The second thing relates to planning an EA effort and optimizing a team. If only 27% of the effort is spent architecting, then about that same percentage of the team should be architects not the entire team. Interestingly, we asked the same group about their team makeup; they stated the following:
45% were enterprise architects
33% were support staff
19% were management
3% were other
This suggests a mismatch. There is a need for business skills to "strategize," and soft skills to "communicate" and "lead." Maybe now is a good time to revisit the charter and ensure that the makeup of the team is right for the job? More information will come as we pour through the data.
- 03 December, 2006 02:21 PM EST
- SOA Not Just a Field of Dreams
- Posted By: Robert Handler, Research VP
In our last poll, we asked how many service-oriented architecture (SOA) projects do you have completed or in development? 138 people responded to this poll. Heres the breakdown of responses:
None: 33.6%
1 to 5: 52.9%
5 to 15: 8.6%
More than 15: 5%
While roughly 1/3 have nothing, over half report between one and five SOA projects or systems. This is significant, given that if asked 2 years ago, more than 90% would have likely responded none.
While the nature of these polls makes it impossible for them to be statistically significant, they always appear anecdotally relevant. This is no exception. SOA appears to be going mainstream not just in thought but in action as well. As always, we welcome your thoughts.
- 03 November, 2006 10:57 AM EST
- Is SOA Agile?
- Posted By: Nick Gall, VP Distinguished Analyst
This is a copy of my response to a thread in the service-oriented architecture (SOA) discussion group. I felt that cross-posting to this blog would open up the discussion to a broader audience of interested practitioners. Feel free to respond to this post or to respond via the discussion group.
The thread began with the question: If an organization chooses to embrace a service-oriented composition/integration method, is it likely to find the process conflicting with one or more of the principles of the agile manifesto?
On 1 November 2006, Dennis Sosnoski wrote: This is an argument that I make in my presentations that the conventional view of SOA is inherently incompatible with agile [G1] practices in terms of the actual development of services. If you're establishing service interfaces that are going to be widely publicized and used, then you lose the flexibility to change those interfaces over time (in fact, I'd say that the guaranteed lifetime of the service interface is an important part of the service definition). Moreover, you have to be very careful and deliberate about what service interfaces to expose in this manner (meaning a lot of advance planning). Both these concerns are incompatible with agile.
This was my response:
I agree 100%. The essential principles of agile are YAGNI , DTSTTCPW, and a development style and tooling that enables continuous/continual re-factoring to incrementally eliminate duplication and add functionality when you need it. For more on the principles, see this simple list.
Now, whether or not you believe these principles are incompatible with SOA depends on whether you think SOA inherently means an enterprisey SOA style pushed by large IT vendors or you believe that a lightweight (dare I say, agile) SOA style is not an oxymoron. I agree with Dennis that the "conventional view of SOA" (read enterprisey SOA) is indeed incompatible with agile principles.
What could be less YAGNI and less DTSTTCPW than putting a SOAP envelope with no headers around an XML payload because you might need SOAP headers later. However, that is precisely the best practice of WS*-based SOA.
In my opinion, Web 2.0 is the prime example of the lightweight style of SOA, and, of course, it is quite compatible with agile principles. In fact, the best Web 2.0 developers exemplify such principles. Of course, most developers would take offense at the SOA label, which they consider inherently enterprisey.
For a great agile [G2] example of figuring it out as you go along, go to code.google.com and look at how many different styles of Web service application programming interfaces the different Google services use. Now, look at how Google is trying to refactor such different ad hoc Web service styles into GData, which was designed after learning from a few years of experience with different Web service styles. Contrast this with the top-down, waterfall, enterprisey approach of conventional large IT-vendor-style SOA, which would have recommended months or years of business process design before defining the first interface.
Note that a lot of large enterprise IT organizations will have no problem with the idea that SOA violates agile principles, since they have already decided not to embrace agile principles.
- 30 October, 2006 09:49 AM EST
- Site Enhancements
- Posted By: Brian Hellauer, Managing Editor, Gartner.com
When you arrived at the Gartner for IT Leaders site, you probably noticed some changes.
First, when you logged in, you were prompted to update your profile information. If you have successfully updated your profile and are reading this, congratulations! If you haven't updated your profile, you'll have to do it soon. Here's a couple of things to keep in mind:
You're going to receive a new password. Your password will be delivered to you via the email address you provide in your updated profile. Once you get it, you can then change your password on the Edit/Save Password page. Every time you change your email address, you'll get a new password.
Submit one section at a time. That profile page does look overwhelming at first glance. You can break the job down into smaller chunks by submitting each of the five sections as you complete them. In total, it should take no more than a few minutes to update your profile, and the information you provide will help us to improve our products.
Second, check out the drop-down menu under "Navigate" on the Gartner for IT Leaders home page. Use this to move among the eight Gartner for IT Leaders roles, including our latest, Program & Portfolio Management.
Third, we've added a Web-based RSS reader so you can manage Gartner research and other content using RSS feeds. It's available under the "Feeds" link at the bottom of the page. Going forward, we'll continue to provide useful tips and advice for using this new feature. In the meantime, let us know what you think.
Recent Posts - Previous Posts
|
");
doParseString("<%parsedinclude(calendar.php)%>");
include("skins/". $skinPath . "/" . $p_blogShortName . "/rec_links_module.php");
include("skins/". $skinPath . "/contact_module.php");
include("skins/". $skinPath . "/tac_module.php"); ?>
|
