As most know, my IT soapbox has “business-driven” emblazoned on all sides. By business-driven, I’m referring to an IT organization’s imperative – to deliver business value.  In this vein, I talk about (harp on) numerous topics including business-focused technology innovation, business-driven architecture, IT gaining business-smarts, and more recently business-IT integration.

I started to use the term 'business-IT integration', because I’m thinking beyond traditional business-IT alignment. Alignment refers to the review and reconciliation of independent activities, in this context the reconciliation of business strategy and plans with IT strategy, architecture and plans.

For business to reap the true value of IT, business and IT must collaborate on the development of strategy, architecture and plans. This collaboration, which should continue through delivery and operations, is business-IT integration. In order to have an integrated environment, business and IT professionals must be more conversant in the other’s discipline. Historically, IT has put this learning burden on the business, but it’s time for IT professionals to 'get business'.

If you bear with me for a moment more, I’d say that business-IT integration will naturally evolve to a business-IT fusion of sorts, at least in the strategy and innovation arenas, but now I’ve gone well beyond the intent of my post…

My intent was to amplify a key message from a MIT Sloan Article on Avoiding the Alignment Trap in IT.  The authors, from Bain & Company, share their “growing realization … that the usual diagnoses of IT’s troubles – and the usual prescriptions for fixing those troubles – are often misguided”. In particular, they call out companies “seeking to deliver higher business value performance by harnessing IT have focused on alignment… the degree to which the IT group understands the priorities of the business and expends its resources, pursues projects and provides information consistent with them”.

The authors believe the following is true "A lack of alignment can doom IT either to irrelevance or to failure”. However, they raise an important flag that every IT leader should take to heart “a narrow focus on alignment reflects a fundamental misconception about the nature of IT. Underperforming capabilities are often rooted not just in misalignment but in the complexity of systems, applications and other infrastructure.”

They go on to describe situations in which business alignment run amok actually drives up IT complexity – silo-ed data centers, customized packaged applications, bolting on legacy applications, lack of standards and shared infrastructure – therefore driving down IT performance.

The authors quote Richard F. Connell, senior executive vice president and CIO of Selective Insurance Group “Aligning a poorly performing IT organization to the right business objectives still won’t get the objectives accomplished”. That, the authors say “is the alignment trap”.

For those in the alignment trap, the authors recommend a return to basics “temporarily focusing on effectiveness at the expense of alignment”. And of course, effectiveness requires simplification. Quoting Leonardo da Vinci, the authors remind us “Simplicity is the ultimate sophistication”.

The article has good insights on diagnosing IT pain and shares company anecdotes. If you have access to MIT Sloan Review, I recommend reading the article.

As for the big takeaway – in pursuing business-driven IT, don’t lose sight of the fundamentals, effectiveness, simplicity (to the degree possible), and constant communication. Host cross project/initiative forums with key players (project managers, architects and business analysts). Open lines of communication and collaboration to help your organization “balance well the needs of the entire organization with those of individual businesses”. And always, beware the alignment trap!

Posted by brendamichelson in Business-IT Integration • business driven architecture | Permalink | Comments (0) | TrackBacks (0)

In October, I asked readers "Who in your organization is the primary source of business-focused technology innovation?".  So far, Chief/Lead Architects are leading that poll, followed by Business Architects/Strategists.

Continuing on the business-focused technology innovation theme, now I'm wondering what impedes business-focused technology innovation.  Essentially, what (or who) holds innovation hostage in organizations?  Or, are there no impediments? 

Please take a minute to answer the quick poll below.  For feed subscribers, the direct poll link is here.

Thanks!

Posted by brendamichelson in business driven architecture • innovation | Permalink | Comments (0) | TrackBacks (0)

[Note: This is also posted on Elemental Links]

The other night I was chatting with a friend about the archetype of business-focused technology innovator – creative, business-smart, technology-savvy, dot-connector, influencer, and transformation leader.  You know, the type of person every organization needs, but doesn’t always know how to find one, or (worse) what to do with. 

Anyway, during our conversation, we were chatting about this archetype versus org chart positions or hiring reqs.  Depending on the organization, a person of this ilk might be found in (or qualified for) one of several slots, from CIO to senior technician.

So, I’m curious, in respect to enterprise or government IT, what role in your organization is the primary source of business-focused technology innovation?  Please note your response on the following poll.  Thanks!

Posted by brendamichelson in business driven architecture • innovation | Permalink | Comments (0) | TrackBacks (0)

Next week, I'll be giving a talk at the Enterprise Architecture Conference entitled "SOA or Business Architecture: Who's on First".  In other words, the title I originally submitted got "punched up" by the conference promoter.  Not surprising, I lack the flagrant self promotion gene.

Anyway, during my session I'll be talking about Business, Service-Orientation, Enterprise Architecture and Enterprise Architects.  With luck, at the end folks should be able to answer the "SOA or Business Architecture Who's on First" question.  (My other option was "SOA and Business Architecture: Chicken or Egg".  Given it's playoff time in Red Sox Nation, I went with the baseball theme.)

If you are attending the EAC conference, please drop into my session or look me up. 

Posted by brendamichelson in business architecture • business driven architecture • enterprise architecture • events/travel | Permalink | Comments (0) | TrackBacks (0)

Continuing on my business-IT integration theme, I want to share some excerpts from a BusinessWeek article, entitled IT's Star Turn.  I found the article via Ben Worthen's BizTech blog.  The article, written by Jeneanne Rae of Peer Insight talks about the importance, and yet dearth, of IT participation in corporate innovation.  Following the excerpts, I have a few questions.  The emphasis is mine.

First, the opportunity: the shift to a services economy, the innovation edge, and the tie to information technology:

"The fundamental shift of the U.S. economy from one based on industry to one based on services has been covered in this column and elsewhere. While some companies—and indeed industries—still resist the trend, the innovators have recognized that the production of value lies in the creation of services, and have adapted accordingly.

Even product-based companies have shifted their focus from the production of physical goods to the delivery of device-enabled services products. But here's the related innovation trend that no one is talking about: Increasingly, those services are being driven by scalable technologies. The information technology departments once seen as back-room cost centers are becoming key players in the execution of innovation, and hence, the creation of value in the new marketplace."

Next, the absence of information technology personnel in the innovation discussion:

"Where is IT in the innovation conversation? With IT being so essential to the innovation equation, and with so much riding on the IT department's ability to build and maintain the systems that will drive customer delight, you'd think there would be more talk about the role of IT in innovation strategy.

But let me ask, how engaged are chief information officers in innovation initiatives? Are members of your IT department full-time members of innovation project teams? Or do they exhibit a "call me when you need me" approach? Or worse still, a "Put your request in the queue, I'll get to it when I can" attitude?

Based on my research, the majority of IT departments sit on the sidelines of innovation discussions when they should be central players. Systems consultants as well as corporate representatives say that, typically, IT departments are tactical rather than strategic, reactive rather that proactive, and isolated rather than integrated. Few in the IT ranks speak "business model," which is unfortunate given that so much customer and shareholder value is dependent on IT solutions to facilitate critical network connections.

...many corporate innovation executives I know no longer consult their IT departments. Despite the risk of exposing new business strategies to potentially untrustworthy third parties during the "fuzzy front end" stage, they simply go outside. "You get tired of hearing, 'no, we can't do that' all the time," said one practitioner at a Peer Insight forum recently."

Lastly, a prescription, or continuation of the Business-IT Integration theme:

"In order to support the robust innovation pipelines that many corporations aim to build, we have to rethink how we integrate IT into our organizations, particularly as it relates to driving innovation. Start with the IT leadership team, where more executive bench strength will be needed. IT managers should be well-versed on managing cross-functional initiatives, and should understand the company's business end-to-end. These managers will need to guide innovation teams in regular technology road mapping and system architecting sessions. Interaction design and rapid prototyping of customer touchpoints will be the standard, not the exception. Iteration and user testing of new software concepts will be a core capability. Likewise, IT must be engaged and mentored by business managers as the opportunities to learn and collaborate go both ways."

Questions:

1. How does IT participate in Innovation at your company?  Are IT personnel at the Innovation table?  If so, which roles?  CIO, CTO, Chief Architect, Business Relationship Manager, other?

2. Are technology capabilities/advancements input to Business Innovation Ideation?  (how's that for a management buzzword?)

3. How integrated are business and IT at your company? 

(a) IT is an order taker

(b) IT aligns with business (IT takes and supports business lead)

(c) IT and Business are integrated: collaborate on Innovation, Strategy, Architecture and/or Portfolio Planning?

Posted by brendamichelson in Business-IT Integration • business • business driven architecture • leadership | Permalink | Comments (0) | TrackBacks (0)

In the January 2007 issue of BPTrends, David S. Frankel of SAP, points out commonalities in leading IT and business thinking regarding loose coupling, orchestration, and eroding silos.  Besides doing a nice job summarizing leading business thinking, David provides an honest look at the current state of SOA adoption:

The preponderance of IT trade press articles and analyst reports leave the impression that SOA, IT’s key initiative of the decade, is spreading very quickly. However, the reality is somewhat different. Many businesses are holding back on making the large IT investments that SOA requires, and IT spending is not ramping up at a pace that compares with previous IT waves. Big upsurges of IT investment occurred in the past when business people could see that the outlays would enable them to reconstruct their businesses in compelling ways.

(emphasis is mine)

and, offers insights on restarting a business-driven SOA conversation:

...the similarity of this thinking to that of IT thought leaders presents an opportunity for IT to work its way back to the mainstream of the strategic business conversation.

Re-establishing Confidence
This is a situation where some humility could help our IT community. We must acknowledge that we have created our own set of rigid silos, and that we have a lot of work to do to remedy the situation. SOA is simply the IT version of the move to evolve to more flexible organizational forms. But if we claim that IT can make the full transition to SOA quickly, or even that we have solved all the problems inherent in such a transformation, it will not take savvy business executives long to recognize the emptiness of such claims.

In an atmosphere where IT approaches the business with candor, we can start a new conversation. We can point out to business executives that if they want to break down organizational silos, arrange the business as a set of loosely coupled assets, and combine and recombine those assets dynamically, then IT must organize its systems that way as well.

What we can offer the business is a partnership entailing a coordinated, at times wrenching, longterm process of change on both sides of the house. If we manage this partnership well, there are ample gains within reach in the short term, and profound advances in the offing for the long term. IT is going to have to act like a mature business unit in order for such a partnership to work. We must recognize that our part of the transition requires more than just “air dropping” an SOA package into picture. We have to take enterprise architecture extremely seriously; the “top gun” mentality that too often prevails in IT is a characteristic of immaturity.

Conversation Pieces
A successful start to the conversation should allow us to begin drawing more connections beyond the basic correspondence of the two camps’ thinking about silos, loosely coupled assets, and dynamically composing assets.

If you get a chance, read David's article, particularly the section on "What Business Thought Leaders are Saying".  I'd also second David's acknowledgment of Jeff Pendleton in bringing forward the business research and business-IT thinking ties.  I've also had the pleasure of conversing with Jeff on this topic.

Another good (related) resource is Hagel and Brown's The Only Sustainable Edge.

Posted by brendamichelson in SOA • business • business driven architecture | Permalink | Comments (3) | TrackBacks (0)

Lately, I've had a lot of conversations on talking about SOA with the business.  Particularly on the best ways to build understanding and gain buy-in.  No surprise, success is greater when IT adopts a business dialect and mindset.  So, I'm curious, when you talk about S-O-A with the business, do you talk in IT terms, or business terms?

S-O-A in IT Terms is:

• Service-Oriented Architecture

• Sharing Our Assets

• Strategy Offering Agility

• Stream of Acronyms

S-O-A in Business Terms enables:

• Strategic Outcome Attainment

• Seizing Operational Agility

• Silo-ed Organization Abolishment

• Situational Optimization Alternatives

• Shedding Obsolete Approaches

• Speed Offering Advantage

Do you lead with an explanation of service-oriented architecture?  Or do you close with a "by the way, service-oriented architecture enables this"?  Are you successful in your messaging?  Why, or why not?

Posted by brendamichelson in SOA • business driven architecture | Permalink | Comments (0) | TrackBacks (0)

The October Issue of Wired Magazine has a good article by Fred Vogelstein on Rebuilding Microsoft.  The article describes the challenges Microsoft faces in competing (surviving?) in a mobile, cloud centric world, rather than the traditional desktop environment, which Microsoft dominates to the tune of $1.5 billion a month.  The article keys on Ray Ozzie (Lotus, Groove), who is succeeding Bill as chief software architect.  Ozzie's vision for Microsoft (and computing) is well known, and best articulated in his services disruption memo. 

The article covers a lot of interesting territory: reducing software complexity, increasing time-to-market, feature bloat versus just enough, seamless platform transitions, xBox profitability, and a return to innovation.

However, the two things that struck me most about the article had nothing to do with technology.  First, was a comment on Ozzie's leadership style:

"...I suppose this is just classic 'walking the halls', but I feel as though without this kind of direct nonhierarchical contact I would lose touch with my organization, and people throughout would know I was disconnected and would lose respect for me."

So true.  You can't be an effective leader (formal or informal) if you aren't in touch with your people.  Sure, it takes a lot of time, but its invaluable. 

Second, was a change to Microsoft's review process for employees:

"In May, Microsoft also changed its review process for rank-and-file employees, who increasingly felt that the system discouraged risk-taking.  It used to be that you were graded on a curve within your group: For every top performer there had to be a subpar one.  That worked fine when the company was smaller.  But as Microsoft grew, the policy encouraged sloth.  Why chance moving to a group of superstar engineers, people reasoned, if it meant you might go from above average status to below average?  Now each employee is graded based on individual goals, regardless of how others do.  These goals are reset as often as every other month to encourage engineers to ship lots of little software modules and revise them online rather than spend an entire year on a huge release".

Here, classic talent management.  The design of employee performance programs must align with corporate goals.  If a company wants innovation, it must create an environment to encourage it.  If a company wants status quo, there shouldn't be surprises when stars bail. 

Note: According to Wired's website, the Rebuilding Microsoft article will be available online on October 6  is now available.  While I could've waited until 10/6 for this post, strong leadership and creating environments for success are soapbox items for me.  Architecture success requires strong leadership -- from architects, and those tasked with leading architects.  On the latter, it helps if you've been the former.

[Post updated on October 11, 2006 at 11:50 for links to Wired article.]

Posted by brendamichelson in business driven architecture • leadership | Permalink | Comments (0) | TrackBacks (0)

Last Friday, I asked if readers were interested in collaborating on questions related to business-driven architecture. This was inspired by a comment from James. Continuing the community-driven theme, I shared a suggested starter question from Mark G.

So one question I would love to hear discussion on is how to prepare your IT organization for Service Orientation. I am curious to see how others are approaching this or not approaching it. I do see it as a challenge for your typical corporate IT shops as oppose to software vendors. What do you think? Is this a big issue for your shops? My gut feeling says that IT shops that have a well established EAI practice or maybe have successfully embraced OO design will have the right mixed of governance and discipline to have a run at SOA. Is this something worth discussing/addressing? Is everyone even looking at SOA now that the hype is at fever pitch?

Some readers sent emails indicating their interest, while others jumped right in. In this post, I'm wearing my host/facilitator hat. I intend to highlight some of the conversation points, provide a chronological tracking of the conversation across the participating blogs (posts, comments and trackbacks) to ease new participant entry, and ask some questions to keep things going. In the spirit of keeping the conversation connection, I'll throw trackbacks from this post. I invite all practitioner readers to participate in this conversation. Here at BDA, on your own blog (please throw me a trackback), and via comments on the community member blogs.

But first, a little housekeeping. Elizabeth Book, ebizQ's editor-in-chief, responded "Absolutely" re: publishing any BDA community generated content. As well, to ease our interaction, the ebizQ technical team added permalinks for individual comments, and you can now subscribe to a comment/trackback feed. [Also available in the Subscribe section of my right sidebar.]

The Conversation: How to Prepare Your IT Organization for Service-Orientation?

[Please note the emphasis below was added by your facilitator]

Todd started the conversation on Tuesday. He disagreed with Mark's "gut feeling says that IT shops that have a well established EAI practice or maybe have successfully embraced OO design will have the right mixed of governance and discipline to have a run at SOA."

Todd stated:

"I think a strong background in these technologies will assist in building service-oriented applications, but I don’t think it will go very far in yielding service-oriented architecture. The reason for this is that as long as all of the IT effort remains within the constraints of a single project, the organization will never understand it means to be a service provider...

...To me, the ability for an organization to succeed is going to be highly dependent on their ability to communicate, collaborate, and manage the service lifecycle, independent of whatever technologies are involved. I had the opportunity to comment about this in the a recent ZapThink podcast."

Mark replied:

It makes me think that when addressing SOA conversations, it’s important to distinguish between the technical aspect and the business aspect.

One thing an EAI competency center helps with is a larger view of the business as well as the various projects within an IT organization. These centers often have a much better view of the world than individual development groups within an IT organization...This one group however cannot transform the entire IT organization however, which is the thought behind my original post. How do you get your IT organization to that state which you are describing?

Anil John joins next, adding important points on SOA being about the business, and the tie between SOA governance and enterprise architecture:

As a technologist it pains me to admit this, but SOA is NOT about technology. It is among other things, identifying the capabilities that are offered by the business unit, having a clear understanding of the processes that make up those capabilities, and making those processes available for reuse via standardized interfaces to the enterprise at large.

...if the culture already has a good governance process in place as part of its Enterprise Architecture, adding the bits that enable governance for SOA is an incremental addition and not a big culture shift. And this addition very much improves the chances of success of the SOA implementation, given that lack of governance has been cited as one of the prime reasons for the failure of SOA implementations.

Todd and Anil are in agreement on a business-first approach. Todd then shares some (good) business process analysis questions to jump start developer's thinking:

1) What services does your solution use / expose?
2) What events does your solution consume / publish?
3) What business process(es) does your solution support?

Knowing Todd, I'm pretty certain "services" in question #1 refers to abstract business services, rather than technical implementations.

At this point, Mark returns here, agreeing with Todd and Anil that a critical step in preparing an organization for SOA is understanding and focusing on the business. However, he brings up a good point, that IT still needs to deliver:

Is it possible to focus on the business but forget that at the end of the day you still have to deliver what you promised? This would be the loosely coupled, reusable and agile services that make up that business process.

The reason I asked is that I have seen many EAI and EDA architectures fail because either the industry/vendors or the IT shop trivialized the technology piece. It's one of those if it were easy then everyone would be doing it. I can tell you that loosely coupled, reusable, agile services are not trivial to most corporate IT shops.

Mark then suggests a natural fork for the conversation:

So maybe the conversation should fork into how do I get my IT organization more involved with the business to really understand it? And how do I make sure that my IT organization can deliver the services that will enable that understanding? What do you think?

Anil and Todd both chime in on steering clear of business process paralysis. Anil offers a mixed top-down bottom-up approach:

Approaching SOA from both the Top-Down/Business Process perspective as well as the Bottom-Up/Service Factoring perspective allows for the identification of the re-usable aspects in a business process and to realize that re-usability using the service implementation technology of your choice. In short, this helps you build the right type of services that are reusable across the Enterprise.

Todd comments on finding the right scope:

Bottom-up efforts are more easily embraced because the starting point is well defined. Top-down efforts, are not so easily embraced. How high up do you go? I think this depends on your resources and the ability of those with business knowledge to contribute. You need to look broader than the bottom-up project at hand, but beginning at enterprise may be too far away to be practical. If the answer was easy, we’d all have done it by now.

Potential Questions to Continue the Conversation:

1. Yes, understanding the business is critical in preparing an organization for SOA. But what else? As Mark asks, how can he ensure his organization is ready to deliver?

2. And the other fork from Mark: "How do I get my IT organization more involved with the business to really understand it?"

3. What tools and/or methods are effective for top-down, bottom-up business and service modeling?

4. How about that "elusive" governance? How do you sell Governance to IT and Business Leadership? Where do you get the money for people, process and tools? How do you convince people "Governance is good for you" rather than "Governance is a roadblock"?

I'd be remiss if I didn't thank our contributors to date. Great thinking. Also, I want to emphasize this is open participation, the more brain power the better!

Posted by brendamichelson in SOA • bda community projects • business driven architecture | Permalink | Comments (4) | TrackBacks (2)

Posted by brendamichelson in business driven architecture | Permalink | Comments (1) | TrackBacks (5)

One of the great things about blogging, is the abundance of tools, services and widgets available to try out.  For the most part, these things are free, and easy to incorporate. 

A feature you'll see soon is a my deli.cio.us integration into my business-driven architect feed.  I make good use of the deli.cio.us' "do not share" feature - so I won't inundate readers with links.

I'll also be adding sidebar content, such as a bookshelf, and of course, blogrolls.  This gets me to my first "call for reader participation". 

I want to create/publish a blogroll of practitioners in business-driven architect type positions. Here's a sampling of names and links I've collected so far: Richard Akerman, MarkG, Mike Herrick,  Sandy, Sam Lowe, Scott Mark, Doug McClure, James, and JT.

What I'd like from readers are submissions of other practitioner blogs you read or write.  Either leave me a comment, or send an email to bda at elementallinks dot com.

Thanks! 

Posted by brendamichelson in blogging • business driven architecture | Permalink | Comments (6) | TrackBacks (1)

Getting through the first post on a new blog can be a daunting task for both the author and reader. So, to save us all some pain, I've chosen a question-driven format, augmented by links to my previous writings. Here goes:

Who am I?

I'm an architect/consultant/analyst/writer/blogger. My background is in corporate IT. My current day jobs are architect-in-residence for the Patricia Seybold Group and principal of Elemental Links. My bio is here.

I'm also (the all too quiet) voice of business-driven architecture. Too quiet until now, that is.

What is Business-Driven Architecture?

Business-Driven Architecture is my view of architecture, developed on the premise that architecture is not an end, but a means, and the business must drive architecture composition.

I believe the most viable, agile architectures will be comprised of a blend of architecture strategies, including (but not limited to) service-oriented architecture, event-driven architecture, process-based architecture, federated information, enterprise integration and open source adoption. How you blend, depends on your business.

In Business-Driven Architecture, enterprise architects are not only responsible for articulating the architecture, but also for actualizing the architecture, and introducing the architecture into IT business projects.

Business-Driven Architecture has a strong bias to action, business opportunity, and project and portfolio advancement.

Who is a Business-Driven Architect?

Enterprise architects who drive the foundational strategies (as mentioned above) that make sense for their businesses, while actively consulting with, and contributing to, business growth initiatives.

The business-driven enterprise architect's responsibilities go well beyond the whiteboard. They need to deliver the architecture (tools, practices, services, and infrastructure), and roll it out to project teams.

Over the lifecycle of an architecture initiative, an enterprise architect might play a variety of roles, including strategist, evangelist, architect, project leader, developer, mentor, and enforcer.

Does that sound familiar? Then you are a business-driven architect!

For more on the Business-Driven Architect, please see my IT Linchpin post at elemental links.

For more of my writings on the architecture strategies: SOA Definitions, Event Driven Architecture Overview, Open Source Considerations, BPEL Primer, and Solving Classic Problems with SOA.

Does this blog replace elemental links?

No! This blog (BDA) and my original blog (elemental links) are complements.

This blog will contain insights, opinions, and references to items of interest to business-driven architects. Expect to see posts on architectural strategies, technology trends, business and relevance.

Elemental links remains the home for my architecture and research projects. As such, that’s the place for long form posts and related heavy lifting.

Why ebizQ?

1. Community - ebizQ's readers and contributors are practitioners, doing real work.

2. Reach – ebizQ has good traction, with the right people. (See #1).

3. Good Company - I know many of the ebizQ bloggers. BethGB and I have known each other for years. Ronan and I have chatted about SOA and semantics over coffee. I read and trade email and/or comments with Sandy, DaveL and James.

What else?

I welcome (encourage) reader interaction! I will (eventually) respond to reader comments and email.

Posted by brendamichelson in blogging • business driven architecture | Permalink | Comments (2) | TrackBacks (4)