Do you have a SOA story to tell?  One that speaks to business value generation, rather than the singular pursuit of technical nirvana?  If you answered yes to both, consider participating in the SOA case study contest from the SOA Consortium and CIO magazine.   Ripped from my own post on the SOA Consortium Insights blog:

"The goal of the SOA case study contest is to highlight business success stories and lessons learned to provide proof points and insights for other organizations considering or pursuing SOA adoption.

Case study submissions must be for completed projects that used a SOA approach to deliver business value.   In keeping with our charter, we are not looking for dissertations on the technical beauty of the architecture and implementation. Rather, we are interested in the business story, the business value generated, the degree of cross-organizational collaboration, and the usages of SOA approaches and supporting technology.

For more information on the contest and participation, please go here."

[Disclosure: The SOA Consortium is a client of my company, Elemental Links]

Posted by brendamichelson in SOA • SOA_Consortium | Permalink | Comments (0) | TrackBacks (0)

Today, I'm in sunny, but not warm, Orlando at OMG's Maximizing BPM Investments with SOA Workshop.  Dave Linthicum just gave a keynote speech.  Here are some quotes from his talk that convey good SOA, BPM and (yes) architectural common sense. 

"The core business motivation is business agility"

"Organizations suffer from the business inflexibility trap.  As a result of years of dragging stuff (new technology) in and bolting it on, IT is impeding business change"

"IT practices (quick hits and bolting on) is like hardening of the arteries.... trouble builds over time and eventually requires  major surgery"

"SOA is not about connecting things, it is about enabling business processes and continual change"

"SOA is also known as good architecture"

"BPM and SOA were never unlinked.  Can't have SOA without process.  Process is more efficient with SOA"

"rather than 'rip and replace' old systems - make them work better together"

"SOA is not about technology, integration or middleware"

"Many perspectives on SOA: Business Processes, Services, Technology and Data"

"SOA is not something you buy, it is something you do"

[Disclosure: The OMG, as manager of the SOA Consortium, is a client of my company, Elemental Links]

Posted by brendamichelson in BPM • SOA • events/travel | Permalink | Comments (0) | TrackBacks (0)

This morning’s dismal US Jobs Report and the ensuing analysis  laden with the “R-word” reminded me of a conversation the SOA Consortium community-of-practice had on our December 4, 2007 call that I had been meaning to post over on SOA Consortium Insights.  During that call, I asked our members the following:

“What does the ensuing (or on-going) economic downturn mean for SOA in 2008? Will the economic downturn and associated budget cutbacks drive organizations to, or away from, SOA in 2008?”

We had a good discussion, the results of which are here.  I'm curious, what does this community think?  Will SOA be employed as a strategy to cope with, and prosper in, tumultuous times?.  Or, will SOA be seen as a budget line to cut?  Let me know, via a comment or trackback, here or there.

[Disclosure: The SOA Consortium is a client of my company, Elemental Links]

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

As most people know, one of my day jobs is Program Director for the SOA Consortium.  This week, our "EA2010" working group published the first release of their view of Enterprise Architecture 2010 in a Powerpoint deck.  Below is a sneak peak.  No surprise for readers of this blog, business architecture is of huge importance.  As are business smarts and business discipline.

In preparation for this release, I sat down with the EA2010 working group leaders, Ashok Kumar and Yogish Pai, to discuss their working group’s motivation, findings and next steps. That conversation is available to the public as an on-demand webcast or podcast.

During our conversation, Ashok and Yogish touched on a wide range of enterprise architecture concerns, including catalyzing business change, gaining business-smarts, shifting focus to business architecture, managing enterprise architecture, participating in strategy and delivery, and winning enterprise constituents.

If you have comments after viewing the webcast, please leave them here, or jump over to the SOA Consortium Insights blog.  The working group members are real enterprise architecture practitioners, and they are very interested in feedback from the broader community. 

Posted by brendamichelson in SOA • SOA_Consortium • enterprise architecture | Permalink | Comments (0) | TrackBacks (0)

Last week, at BPM Think Tank I shared some of the SOA Consortium (and my) views on the complementary relationship of BPM and SOA. I purposely kept the conversation away from technology and standards. Instead, I focused on the changing role of IT (value generation), the problems BPM and SOA solve (instantiating business scenarios which are comprised of processes, activities, services and events), the changing role of enterprise architecture (business architecture as first class citizen), the importance of business and IT collaboration on enterprise strategy and enterprise architecture, and the need for IT professionals, particularly architects, to gain business smarts.

On Monday, I read an article in the online WSJ, What's Next for IT, that echoed many of these themes, and provided some additional insights into the question Phil Gilbert posed "How are organizations injecting business smarts into IT professionals?"

The article is an excerpt of an interview between WSJ editor Francesca Donner and three CIO's -- Meg McCarthy of Aetna Inc., Frank Modruson of Accenture Ltd. and Steve Squeri of American Express Co.

While the entire article is worth the read, I wanted to excerpt some of the excerpt, particulary on the topics I mentioned above. My categorization has caused some selections to be ordered differently than the article.

On the changing role of IT: "Strategic" and "At the Table"

THE WALL STREET JOURNAL: Analysts have written that IT departments are becoming more strategy- and business-oriented. Do you agree?

MS. MCCARTHY: I totally agree. At Aetna, the IT organization is critical to enabling the implementation of our business strategy. I report to the chairman of our company and I am a member of the executive committee. In that capacity, I participate in all of the key business conversations/decisions that impact the company strategy and the technology strategy.

MR. SQUERI: I believe that over the next 10 years, the CIO will get more involved in the overall business strategy of the company and see their role expand in importance. The CIO will be increasingly called upon not only to translate business strategies into capabilities but to become even more forward-looking to determine what capabilities the business will need in the future.

The days of tech leaders as relationship managers and "order takers" will go by the wayside and they will be called upon to create and drive technology strategies that drive business capabilities.

On bridging the Business-IT divide... "Business-IT Integration" (my term)

MR. SQUERI: I agree that technology organizations are getting closer to the business. It's a must.

This doesn't happen overnight, though. We need to help the business better understand technology. We need to help our technology employees better understand the business strategies.

One way we are doing this is by moving people across the organization, from the business to tech and vice versa. Alignment with our senior leaders helps build the connection at all levels within the organization -- we're all at the table together.

MS. MCCARTHY: Steve's note is very consistent with some of the strategies we are employing [at Aetna] to bring greater alignment with our business partners.

Transitioning people from the business into IT and rotating IT people to the business brings a greater understanding to the broader organization.

MR. SQUERI: For businesses that leverage information or use technology as a competitive advantage, it is important that business leaders know how to leverage the technology groups to enable their strategies. This means that just as technology groups are learning to translate business strategies into technology capabilities, business leaders will have to think about their strategies in terms of long-term capabilities.

The only way that can really take place is by deepening the working relationship and ensuring that IT has a seat at the table.

MS. MCCARTHY: Our current CEO and chairman has a technology background which has been invaluable to our business at Aetna. He encourages all our non-IT leaders to have a good working understanding of technology and to understand the systems that enable their business areas. He also has the business leaders report on all the "systems" projects/programs for their business areas -- a recognition that this work is not just systems work but business and systems work.

I would encourage all non-IT managers to get an orientation to their systems organization. I would also encourage non-IT leaders to spend time with their IT partners, particularly the architecture team during their strategic planning process. Have the architecture team look out three years and identify technologies that could be applied to the business to improve productivity or increase revenue. Working together on these things can generate creativity on both sides.

On SOA, Service Definition and Business Process, "Bi-directional Business-IT Understanding"

MS. MCCARTHY: ...The other important aspect associated with Steve's comment and his business background is the focus that most of us have on building a services-oriented architecture.

The analogy that I'll use here is Legos. In a services architecture, we build discrete services that are individually tested and certified, versus a more traditional programming method. These services can be used and reused very efficiently, i.e., the Lego concept of taking Legos apart and reusing them to build something new. The promise of this approach is significantly reduced costs and speed to market. The ability of the IT organization to do this work efficiently is a function of how well we work with our business partners to define our business processes at the right level...

... The big challenges for most companies will be the continued work on building an adaptable architecture that provides for seamless interoperability with other companies, i.e., ease of communications and transaction processing with business partners and customers.

The CIO in this work will be an important strategic partner who can educate and vision with their business partners. [As CIOs] we need to understand the business, the technologies that are evolving and work closely with our business partners to identify opportunities for the company and our customers to exploit these technologies to achieve market leadership and competitive advantage.

On Next Generation Technology Leaders:

MR. SQUERI: I believe that finding the right talent is a key priority and challenge we're facing.

We all talked about the need to align technology and business strategies. Part of getting there is bringing in and developing people with technical, business and management skills. Our technology leaders need all of these skills to be successful and make our businesses successful.

Posted by brendamichelson in BPM • Business-IT Integration • SOA • business • enterprise architecture • general IT • leadership | Permalink | Comments (0) | TrackBacks (0)

If you are going to Gartner's AADI Summit next week, make a point of attending the User Panel: Best Practices in Advanced SOA for the Enterprise, on Wednesday, June 13 at 11:00 am.  This high talent practitioner panel was put together by the SOA Consortium.  I've had the pleasure of interacting with each panelist, Nida Davis, CTO, American Red Cross, Surekha Durvasula, EA Manager, Kohl's and Yoav Intrator, CTO, Deutsche Bank Asset Management.  Each is experienced in SOA, enterprise architecture, and delivering value to the business. 

If you are attending the co-located EA Summit, you should catch Nida's case study session with one of her former business clients at the Federal Reserve.  And while I'm recommending practitioners I enjoy speaking with, go see John Turato's case study session on SOA and the Legacy.

Normally, this is where I tell you to contact me if you'll be at the event.  However, I'll be in Cumberland MD, representing the SOA Consortium at ArchitectureGov.  I'll be hosting a roundtable discussion on SOA, enterprise architecture and business architecture.  So, if you'll be there, drop me note: bmichelson at elementallinks dot com.

[Disclosure: The SOA Consortium is a client of Elemental Links.]

Posted by brendamichelson in SOA • SOA_Consortium • events/travel | Permalink | Comments (1) | TrackBacks (0)

Wall Street & Technology has a good article on SOA for Business Transformation in banking.  The article speaks to SOA implementations at Wachovia and Bank of America, and is supplemented by commentary from Microsoft, Tower Group and Butler Group. 

Below are some excerpts of interest that align with findings from the SOA Consortium's Executive Summits and (of course) my own soapbox.  I skipped the detailed technology sections, because that's the easy part. (The headings and emphasis are mine)

Business-Driven SOA

"Charged with differentiating the bank and growing its business in the face of larger-scale competitors, Wachovia's CIB division had to map out where its technology needed to be to match where it wanted the business to go, relates Bishop."

"As Wachovia and other banks are discovering, leveraging SOA's loosely coupled services to overcome siloed technology has the potential to completely change a financial institution."

"Approaching SOA with clear business goals and realistic expectations may be the most important step a bank can take, Wachovia's Bishop says. Although Certoma set the ultimate goal for the bank's SOA transformation as business differentiation, she also outlined more-specific subsets of the project, including decreased time to market and cost of delivery for new products, Bishop points out."

SOA is Not a Slam Dunk

"Yet the road to a full SOA implementation is marred with potholes and roadblocks, and according to experts, it's important for financial institutions to be aware of the key decisions they face about services, technology and governance."

SOA Infrastructure Should be Flexible

""Wachovia required that all its technology be componentized and capable of being extracted, the bank's Bishop says. Wachovia didn't want any technology built to a specific language or a specific format. "This is where a lot of SOA strategies fall short," Bishop asserts. "A lot of people in the past would build business logic and need to inherit that it was running on a Java container. We didn't want that. We wanted to reuse so that it could be moved about in different ways." According to Bishop, he bought a lot of best-of-breed technologies that are open standards-based and pluggable."

Governance and Portfolio Management -- People, Process, Tools

"To manage business components and services along with infrastructure services and components, Wachovia's Bishop relates, the bank's CIB division created a portfolio management function, in terms of personnel and tools, to govern the project and track the usage of those elements. The first step was to create an open source community, which set specific rules in terms of what the CIB's business units could contribute or use, according to Bishop. The second step was to establish peer groups across the various applications to understand who built what, how it was being used, who reused what and how it was reused, he adds. The third part of the governance plan included mandates that each development team contribute and/or reuse various components of the SOA as part of their annual objectives. And finally, Bishop notes, the CIB division created a steering committee that prioritized projects.

Bank of America delegated governance for SOA to the four CIOs within the organization, the bank's Conroy says... While Conroy says he has a pretty tight grip on technology and product governance, he's still trying to "work out the kinks" when it comes to governance over services. Service-level agreements across CIO units are the next hurdle, Conroy says, especially figuring out how to price services and allocate costs. "The two things that make SOA hard to do in a big group are governance -- who can generate the requirements and decide what your billing is -- and who pays for it," he contends."

Business and IT Collaboration Required

"An SOA implementation will bring about many changes in the financial institution, including new partnerships between business and IT, according to TowerGroup, which asserts that such partnerships are integral to overcoming the challenge of breaking down the walls between businesses in the bank."

"Bishop offers advice for banks just starting on their SOA journey. "You've got to focus," he says. "You've got to be committed. You need to do it in incremental building blocks. SOA needs to be business-aligned and needs to have a top-down map and a bottom-up approach." And bank executives need to know what they're getting into: "It's a full-time part-time job for even the highest-ranking executives," Bishop says."

Posted by brendamichelson in SOA | Permalink | Comments (1) | TrackBacks (0)

Amr Elssamadisy has started a new series/discussion at InfoQ on SOA and Agile.  The initial article asks "SOA and Agile: Friends of Foes".  This is similar to a conversation we had here last summer.  Including the high quality comments.  Below are some excerpts.   I disagree with the last two clash bullets, especially the third.

Article Open:

"SOA aims at making the entire enterprise agile by using services as the building blocks for applications. Agile software development aims at making organizations agile by introducing practices that increase communication and feedback. Which is right? Which is better? Are we comparing apples and oranges? Can they be used together, and if so, how?"

On the Friends side:

"SOA and Agile share the same broad goals. They both recognize that change is an inevitability and that organizations need to effectively cope with that change. So we would expect that Agile is by default the methodology of choice when building SOAs and vice versa - right?"

On the Foes side:

"One of the main reasons is that they come at the problem from different roots and initially different directions. Agile is historically grass-roots and small-project based, although throughout the past years the community has gained experience and learned to adapt the principles of the Agile Manifesto to large projects. SOA is a newer initiative and is top-down in nature and takes a divide and conquer approach to software development. This approach, especially the 'divide' part, typically results in low-bandwidth communication between teams such as documents, specifications, etc... .

Specifically, here are three areas where SOA and Agile clash:

• SOA encourages that architecture be upfront while Agile has a derogative term for this approach coined BDUF.
• SOA encourages teams split along functional lines while Agile encourages cross-functional teams.
• SOA does not have a position with respect to feedback and change of the services once they are built while Agile is focused on frequent and feedback at both a technical and personal level."

I encourage you to read the article and the comments. 

Posted by brendamichelson in SOA • agile | Permalink | Comments (1) | TrackBacks (0)

This week, I've been working on a whitepaper write-up of the Insights from the SOA Consortium's Executive Summits.  This paper goes deeper than the Top 5 Insights we shared in the webinar. 

Last night, I wrote this:

"To collaborate effectively, business and IT professionals must speak a common language.  Historically, business professionals have been encouraged to increase their IT literacy.  This has proven successful at the project execution level.  However, collaboration on strategy and architecture is a business conversation first. 

“Our entry is always the process and that’s what we actually talk about – how to optimize the process, how to drive the process…When I hear business people talk about systems and they mention System A, System B, System C, I know we’re in trouble.  Because basically that means to me is that we are locked into the constraints of the environment.” – CTO during SOA Executive Summit

The CIO and CTO participants encourage business-smarts in their IT organizations.  IT professionals, particularly senior leaders and enterprise architects, must understand the business, and be able to relate IT capability to business value generation."

This morning, I saw Jon Udell's post on "Talking to Everyone", in it he asks:

How do you talk to everyone about the transformative benefits of the technologies we’re so excited about, in ways that don’t make people flip the bozo switch and tune you out? How do you tell stories that make the benefits of the technology come alive for people, in ways they can understand, without overwhelming them with technical detail, but at the same time without dumbing down your explanation of the technology?

So, I'm curious.  What techniques, metaphors, or stories do you use to "talk to everyone" about SOA?  Enterprise Architecture?

[Disclosure: The SOA Consortium is a client of Elemental Links]

Posted by brendamichelson in SOA • SOA_Consortium • enterprise architecture | Permalink | Comments (3) | TrackBacks (0)

[Updated Friday, March 23, 2007 for links to slides and replay.]

During the last week of February, I facilitated a series of SOA Executive Summits for the SOA Consortium.  The purpose of the Summits was two-fold.  First, was to validate the mission, vision, goals, strategies of the SOA Consortium.  Second, to have a roundtable discussion on the real-world challenges, issues and opportunities discovered by leading SOA adopters.  The attendees were CIOs and CTOs of organizations you would easily recognize. 

As I mentioned last week, I've been under a gag order in respect to the Summit results.  However, that ends Tuesday at 2:00 EDT.  Richard Soley, Executive Director of the SOA Consortium, and I will be presenting the "Top 5 Insights" from the Summits in a webinar.  Having identified the "top 5", I can tell you they aren't the same topics you hear in everyday SOA conversations. 

So, if you have a chance, check out the webinar tomorrow.  We'll be live, which means anything could happen.  Just direct the hard questions at Richard.  After the webinar, I'll add. Link to the slides and replay.

[Disclosure: SOA Consortium is a client of Elemental Links]

Posted by brendamichelson in SOA • SOA_Consortium | Permalink | Comments (0) | TrackBacks (0)

Posted by brendamichelson in SOA • SOA_Consortium • enterprise architecture | Permalink | Comments (0) | TrackBacks (1)

Earlier today, The Open Group formally announced its new professional association for enterprise architects.  I had the opportunity to speak with Allen Brown, The Open Group's CEO, last week about the association (AOGEA), enterprise architects as city planners, business architecture, and membership qualifications.   Sadly, I don't qualify for full membership, because I'm not TOGAF or ITAC certified, but there are other levels (associate and affiliate) for enterprise architects (and enterprise architect types) interested in joining.

Allen Brown shared that the primary drivers in escalating the role of the EA:

• "The breaking down of barriers within and between enterprises demands a city planner perspective of the enterprise architecture
• Enterprises need assurance that the staff or service providers they hire have the skills and experience necessary to address the complexities of enterprise architecture
• Professional enterprise architects need a recognized, portable and professional grade qualification"

Since Gian Trotta has a post and podcast on the AOGEA, I'm just going to skip ahead into 'enterprise architects as city planners'.  I hope to have information on The Open Group's Business Architecture working group in a couple of weeks.

In our conversation on enterprise architects as city planners, I shared that whenever my father asked me what I did (as a chief architect) I said, "think of it like city planning for business applications".  That would resonate.  And move my father along to how his Yankees beat my Red Sox, or vice versa. I'm sure other enterprise architects have had similar conversations.

I also shared with Allen Brown that I just read a fabulous, unpublished, paper by Annie Shum of BEA on "Connecting the Dots".  Annie's paper covers a range of topics -- meta-principles, fractals, complexity containment, services, SOA, networks of networks, grids of grids -- along with one of her favorite metaphors: SOA and city planning.  Annie has graciously given me permission to excerpt (liberally) from her paper.  What follows are some of Annie's thoughts on SOA, enterprise architects and city planning.  Enjoy!

"...Perhaps one of the most instructive metaphors for SOA is the process of city planning. As I wrote in my SOA & City Planning paper, city planning is not concerned with the design and construction of individual buildings. Rather, it is concerned with the multi-aspect relationship of individual buildings to one another, to the areas of the city/community where they are constructed, and to access to common infrastructure services such as electricity, water, and sewage. In other words, city planning is not about building architecture; it’s about meta-architecture for designing communities of buildings by focusing on common infrastructure, governance and cohesion. Filtered through a meta-framework prism, the similarity between city planning and SOA is remarkable. Whereas city planning is the meta-architectural framework for building communities, SOA is the meta-architectural framework for collaborative computing.

City planning is a separate profession, distinct from the activities of architect, carpenter, or electrician. In the software development community, carpenters and electricians might correspond to software developers, and architects might correspond to analysts who write specifications for applications. The initial hurdle with this metaphor is that, in most cases, the existing software development community has no de facto analog to the city planner. SOA is destined to resolve this problem by driving into the mainstream a (relatively) new category of IT/business professional, the enterprise architect, whose range of responsibilities is similar to that of a city planner.

Like a city planner, the enterprise architect must have a “big picture” vision that transcends individual units (buildings, services) and focuses instead on the way collections of units (neighborhoods, communities) can fulfill a variety of different purposes. A manufacturing community might consist of a cluster of factories surrounded by homes for workers and connected by railroad links to suppliers of raw materials and component sub-assemblies, as well as to merchants who sell the manufactured products. The community has a need for schools, recreational facilities, police and fire stations, food markets, and so on. Each of these individual facilities could also be used for other purposes. For example, the worker housing could also be used by individuals who do not work at the manufacturing facility, the rail lines could be used to ship goods used for non-manufacturing purposes, and so on. The city planner needs to think about the full constellation of sharable resources that need to be assembled and coordinated.

These observations about city planning illustrate some highly relevant design principles that tomorrow’s enterprise architects should heed when designing specifications for SOA-based IT services. Simply put, enterprise architects must shift their mind-set from today’s stovepipe approach to a connected, virtualized, and federated ecosystem. Unlike the traditional software application architects, the enterprise architects’ role extends well beyond software coding specifications. Instead they must also act as the chief enablers of borderless collaboration by coordinating and prioritizing the input from disparate groups with different needs, interests, and views, including business stakeholders, software architects, developers, and DBAs, as well as external partners, suppliers, providers, customers, auditors, and so on.

One fundamentally important point for enterprise architects is that specifications should be flexible enough to allow for creativity, variability, and initiative in the design and implementation of individual units—whether these units are “bricks and mortar” buildings or individual IT services. However, this heterogeneity must be uniformly constrained by explicit boundaries and formal core tenets for each service in order to achieve the holistic cohesion that enables borderless collaboration and leverages IT asset reuse and the sharing of common infrastructure services.

...

Another important lesson from the city planning metaphor is the co-existence of the old and the new.

...

Managing growth by clustering neighborhoods into communities, communities into cities, and cities into regions is another lesson of city (and regional) planning that has far-reaching applications for enterprise architects designing scalable SOA ecosystems. The fractal-like nature of services allows them to be composed into composite services, which can then be composed into higher-level composite services, and so on. This hierarchy of composite services operates like a nested set of worlds within worlds and makes it possible for each service to retain local autonomy over its own internal operations while also containing complexity and maximizing global interoperability and connectivity through standards-based shared common interfaces. Emerging concepts such as “networks of networks” and “Grids of Grids” exemplify these principles and give new meaning to the old political maxim of “Think globally but act locally.”"

Posted by brendamichelson in SOA • enterprise architecture | 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)

Perhaps I need more coffee, but this amused me this morning:

Posted by brendamichelson in SOA | Permalink | Comments (3) | TrackBacks (0)

Last week I concluded my 2006 travels with stops at CMG2006 and a SOA Alliance meeting.   My CMG2006 session was "Observations from the Field: Tackling the Hard Parts of SOA":

"Enterprise architects and technical leaders consistently state the hardest part of SOA is not the technology. Rather, the real work is in service definition, semantics, establishing an SOA program (evangelism, planning, governance, infrastructure and tools) and wading through the industry hype. This presentation delves into the hard parts of SOA, and shares real-world practitioner tips for success."

The presentation was based on a paper I wrote during the summer, with some additional observations/tips and illustrations.  I also added a new section on capacity planning/usage prediction, to elicit tips from the audience.  More on that later.  For now, I'm posting my SOA Hype slide, because there was audience interest in reusing it.

Several notes:

• The slide was produced in late October, the same Google search today yields "34,700,000 for service-oriented architecture."
• The SOA Re-use break even of 1.3 is from Jeffrey Poulin's work.
• For realistic numbers on SOA adoption, see ebizQ's SOA Governance Survey Results. 
• The great Web Services Standards poster is here.

The slide...

Posted by brendamichelson in SOA | Permalink | Comments (0) | 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)

Today is the third day of the Office 2.0 Podcast Jam.  So far, 8 podcasts are available.  All touch on different aspects of, as Cote says, "*2.0" (Office, Enterprise, Web).  Richard MacManus provided a great keynote on Office 2.0 as a paradigm shift.  He spoke of the importance of "Web native functionality" in "office" applications.  Anne Zelenka, the jam founder, conducted a jolting interview on what it really means to be a paperless office in Afghanistan.  Laura Blankenship described the barriers to *2.0 adoption in higher education.  Scott and Cote seemed to have a great time talking about Identity, Learning and Shame.  Ken Camp talked about the importance of presence, relevance and availability in respect to VOIP platforms.  Greg Olsen spoke of businesses "going bedouin".  Eric Severson spoke on the rules of Office 2.0, which I then proceeded to break in my mixing "*2.0" and SOA for a business-focused Enterprise Toolkit.

I've enjoyed all the podcasts, and have made notes to check into the following: dabbledb, coghead, zimbra, and embedded presence.  I'm sure that list will grow as the week goes on.  The great thing about these podcasts is they are informative, yet short.  The longest one is 15 minutes.  The average seems to be 7 minutes.  So, if you have a break between meetings and/or phone calls, jump on over.  I know I'll be back, I want to hear what Sandy has to say on "Web 2.0 and BPM", as well as the latest from the Office 2.0 conference (travel required to that one!).

For those interested in the technology behind the jam, see this post of Anne's.  For my own podcasting, I used Audacity and followed these instructions.  It was pretty simple, even for a podcast newbie. 

Tags: office20jam

Posted by brendamichelson in "2.0" • SOA • events/travel | Permalink | Comments (0) | TrackBacks (0)

Lately, every time I start a post on an interesting SOA paper, Joe gets there first!  Not so this time...

During BEAWorld San Francisco, BEA released a practitioner written and reviewed SOA Practitioner's Guide:

"To help develop a shared language and collective body of knowledge about SOA, a group of SOA practitioners created this SOA Practitioners’ Guide series of documents. In it, these SOA experts describe and document best practices and key learnings relating to SOA, to help other companies address the challenges of SOA. The SOA Practitioners’ Guide is envisioned as a multi-part collection of publications that can act as a standard reference encyclopedia for all SOA stakeholders."

The guide has three chapters, each a standalone document: Why SOA?, SOA Reference Architecture, and Introduction to Services Lifecycle. 

When I reviewed the guide, pre-publication, I commented back to the authors that I found the Services Lifecycle chapter most interesting, because it focuses on "How" (not "What"), and its obvious the advice came from practitioners, in large environments, with active enterprise architecture practices and a slew of technology and applications.

"Chapter 3: Introduction to Services Lifecycle.  It provides a detailed process for services management though the service lifecycle, from inception through to retirement or repurposing of the services. It also contains an appendix that includes organization and governance best practices, templates, comments on key SOA standards, and recommended links for more information."

While you might not agree with all of the answers presented in the SOA Practitioner Guide, the guide is of tremendous value in that it raises many relevant questions.  I know from my own experience in leading IT transformation, one of the hardest things to do, is figure out all the things you have to do.  And for that reason alone, I recommend taking a look at this guide. 

Two comments on the content itself.  First, the SOA Reference Architecture is extremely BEA (JEE, Portal, ESB) heavy.  But, as Yogish Pai pointed out in a conversation, and in the guide, the Reference Architecture is presented as "an" SOA reference architecture, not "the" SOA reference architecture.

Second, in the "requirements and analysis" phase of the service lifecycle, the guide (correctly) identifies business centric activities, such as business modeling and capturing business motivation, but then lists architects as 'optional' participants in this phase.  I disagree.  I think architects should take every possible opportunity to interact with "business" folks and a business modeling session is a great place to start. 

The more architects can learn about, think about, and converse about their business, the greater the likelihood architecture will be seen (funded) as a business enabler (think innovation), rather than an IT enabler (think TCO containment).  Perhaps this falls into the role of the business architect?

Posted by brendamichelson in SOA | Permalink | Comments (3) | TrackBacks (0)

This morning, webMethods announced it has agreed to acquire privately-held Infravio for approximately $38 million in cash. This acquisition comes on the heels of webM's purchase of semantic metadata management technology company, Cerebra.  Technology from both acquisitions will be incorporated into a future release of webM's Fabric.  The answer to the burning question for current customers - "Will Infravio's products continue to be offered and supported standalone" - is "Yes".

Of course this is just the latest acquisition in the "SOA Governance" space.  [I use quotes because there's more to governance than what comes in a box.]  On August 23, BEA announced its acquisition of SOA repository vendor Flashline.  And on July 25, HP announced its acquisition of Mercury - the new owner of Systinet.  With Systinet, HP got the registry embedded in Oracle's Fusion and BEA's AquaLogic.

This makes LogicLibrary, a design time metadata repository and registry for SOA (and more), as the last independent standing.  Looking at the names above, the natural assumption is LogicLibrary is next, perhaps by IBM.  However, IBM embarked on a build plan for WebSphere Registry and Repository, and appears to be readying for an October launch. 

This recent flurry of activity centers on design time metadata management, with hooks to runtime.  The next frontier will be integration with IT operations (CMDB, ITIL, SML).  Or as Todd says, the repistry.  On that front, IBM picked up asset management software vendor MRO Software in August.

Speaking of enterprise level metadata management, I find myself intrigued with IBM's Viper (DB2 v9), the hybrid XML/relational database.  What role will Viper play in IBM's plans? 

Anyway, I digress.  It looks like enterprises now have 3 choices in respect to design time "SOA Governance":

1.  Adopt the registry/repository of your primary SOA platform provider (BEA, IBM, Oracle, WebM etc).

2.  Adopt the registry/repository of your enterprise systems management provider (HP, IBM etc)

3.  Go independent: LogicLibrary.

There is no one right answer.  As always, act for your business.  Keep the bigger (metadata management) picture in view.

Update: 9/11/2006 11:52am - Forgot the disclosure:  None of the vendors mentioned in this post are clients of my firm, Elemental Links.

Posted by brendamichelson in SOA | Permalink | Comments (0) | TrackBacks (0)

I'm visual by nature. I think and communicate best with a pen in my hand.  I work through ideas by drawing - mixing mindmaps, components, parties, flows, interactions and layers. I grasp concepts best when visual elements are present.  More often than not, I ask people to show/draw me a picture.  I recently bought a Tablet PC, and wonder how I survived previously.

No surprise then, I'm extremely interested in the visualization of information and intuitive interface design.  On the latter, Irving WB recently posted his thoughts on human oriented design:

I really believe that one of the most important and exciting areas of innovation is to rethink IT applications around the humans that use them not the computers that run them.  In fact, I feel that we do not have a choice -- if we want to stay one step ahead of the growing complexity of the IT systems around us.
    
When one examines the characteristics of successful IT applications – those that appeal to large numbers of people -- it is clear that they appeal to us because they are intuitive and thus easy to learn and use.  What makes applications intuitive is the fact that they are designed around objects from the real world that people are generally familiar with, and thus we can bring our real world knowledge and intuition to bear on the applications - they have a point of connection, as it were. 

The applications are then developed for the virtual world of computers, including the realistic simulations of the physical world objects on which they are based, along with added features which good designers will also make as intuitive as possible.  Since our interactions with the physical world are so visual in nature, it is not surprising that the more visual an application, the more intuitive it is likely to feel.

Are you thinking, "Ok, interesting.  But what's the tie to SOA Testing?"  Last week, I was briefed by SOASTA on the alpha version (yes alpha) of their SOA testing product, Concerto.  Concerto is designed on the visual metaphor of digital media creation - think iMovie, iPhoto, GarageBand.  You work with visual elements for messages, clips (groups of messages) and compositions (groups of clips).  Compositions are your test scenarios.  You can run (play) multiple compositions (concurrently, staggered) on a timeline based mixing board.  Below is a screen shot of the mixing board (composition editor) captured from the SOASTA Concerto Quick Tour.

As part of SOASTA's launch, they are introducing the team and product through video podcasts.  The first one was about the team.  The second, to be posted, promises an introduction to the product.  Definitely a product to keep an eye on, for its visual innovation, and the power that comes with it - intuitive SOA testing for business analysts.

[Disclosures: Neither IBM or SOASTA are clients of my firm, Elemental Links, Inc.]

Posted by brendamichelson in SOA • visualization | Permalink | Comments (2) | TrackBacks (0)

Updated 8.23.2006 at 11:04 to insert "DRAFT" into the post title, and add the following clarifying note:

The linked document is a "work in progress", and not (yet) an official RFI.  In other words, please review the RFI for content (additions, changes, deletions), not for submitting a response.  Thanks.

[The original post starts here]

For readers of elemental links, this is a duplicate post. I'm going for max reach!

The Object Management Group’s SOA SIG is looking for community (practitioner, vendor, researcher, observer) feedback on a draft request for information (RFI) on event-driven architecture (EDA) and its relationship with service-oriented architecture (SOA) & business-process management (BPM).

Here’s the RFI Summary:

The EDA Sub-group of the OMG SOA SIG seeks information from members of the EDA, BPM and SOA community as well as anyone interested in promoting standards in this area. Requested information will be evaluated by the EDA Sub-group, resulting in the development of Requests for Proposal(s) (RFP) for standardization of Event definition, relationship between EDA, BPM and SOA that will ultimately allow development of standards for Complete Life Cycle of Events -Ontology of Events, Sense and Respond Services, Events Metrics and processing of complex events. Please note that it is our intent to develop modeling standards for the EDA/SOA and EDA-Business Process interaction and provide standards for the implementation of that interaction as well.

For those (like me) not completely familiar with the OMG process, here’s the description of the RFI process taken from section 8 of The OMG Hitchhiker’s Guide, V7.3:

The intent of the Request for Information (RFI) is to gather information for the purpose of guiding a subgroup in its efforts to provide solutions to industry problems. The RFI is an optional process used by a subgroup to canvass a targeted industry segment for one or more of the following purposes:

• Acquiring general or specific information about industry requirements.
• Soliciting assistance in identifying potential technology sources.
• Soliciting input to and validate a subgroup’s roadmap.

Generally speaking, the RFI process determines which Request For Proposals (RFPs) get issued (and, based on negative feedback, which don't) or influences the way a particular RFP is constructed.

There are no restrictions on who may receive or respond to a RFI. Both OMG Members and non-members can respond. RFI Responses may include information about relevant technologies, products, standards, research, requirements, and other guidance for the subgroup.

If you are interested in EDA (simple, stream, complex), take a look at the RFI and provide comments to Dr. Harsh Sharma. The plan calls for a final review of the RFI at the OMG’s September Technical Meeting in Anaheim.

I suppose this is where I say “I’m going to Disneyland!” I am a guest contributor (no $ exchanged either way) to the EDA subgroup of the OMG SOA SIG.

Posted by brendamichelson in EDA • SOA • architecture strategies | Permalink | Comments (0) | TrackBacks (0)

Last week's post on Agile & SOA has generated some great conversation.  There is general agreement that Agile and SOA share values, particularly around the end goal of business responsiveness.  The question though, is how to provide that responsiveness (velocity and flexibility), in a sustainable manner (architectural integrity).  Themes that emerged in the comments were separation of concerns, increments vs. iteration, and the three C's: communication, coordination and collaboration.

Today, I'm pleased to add another voice to our conversation.  Annie Shum, a leading SOA and technology thinker, was kind enough to share her views on SOA and Agile in an email conversation, with permission to post here. 

In the first business-driven architect guest post, I’m thrilled to publish Annie Shum on Agile and SOA:

“Adding a bit more to the discussion but from a different perspective based on my favorite metaphor of SOA analogous to a set of architecture and urban city planning blueprints plus administration policies whereas developing software is more akin to building buildings, bridges, or other structures in a city.   

The former is a meta framework where city planners, building architects, policy makers, construction contractors, government officers including zoning permits etc have to come together to create a master plan through  collaboration & communication - all under some explicit as well as implicit policies & overarching governance. It’s not about the city planners dictating individual buildings but more about the overall cohesion of the city: the neighborhoods/community planning including security (courts, police buildings, fire stations etc), education (schools, libraries) and recreation (parks, zoos etc).  The relationships matter more than the individual structure to the city planners.  Meanwhile, the contractors can go ahead and build the buildings according to their own business models as long as they comply with the master blueprint of the city planner office, the zoning laws, leverage the common infrastructure based on city standards etc.

To cut to the chase, that’s what Agile vs SOA is all about. Historically, software development has been by and large project centric. To me most software development projects are still akin to “building little house on the Prairie”. Whether you use Agile or waterfall approach has both pros and cons. Obviously Agile has a lot of compelling benefits (note: I favor Agile) but only work effectively if there is constant communication between management and developers as well as clearly spelled out accountability methods to manage rogue development. Above all, transparency is critical regardless what technique is used: agile or otherwise.

In a SOA shared service ecosystem, so long as the enterprise architects act as the city planners and work collaboratively with business process owners, LOB exec, software architects, developers, database architects IT staff, capacity planners, performance analysts, etc to create a cohesive set (maybe incrementally) of architectural patterns, blueprints, what services to share, what standards to comply, what policies to follow and to specify etc,  then the software architects & developers are in theory free to implement their services (encapsulated by standards based interfaces, contracts and policies) and composite app using their technology choices and development approaches: Agile or not or more likely a mixture of agile and traditional method…

So it hinges on the SOA ecosystem cohesive architectural patterns, policies and blueprints that act as the beacon & “glue” for the enterprise. That’s why reflective modeling is so critical: it’s the closed loop modeling process from begin to end throughout the lifecycle of services that can guide this complex SOA transformation. Having a pervasive metaframework for modeling different aspects of SOA, I see Service oriented based modeling as the intermediary and the bridge connecting business & IT as well as connecting architecture patterns with software development."

Posted by brendamichelson in SOA • agile | Permalink | Comments (0) | TrackBacks (0)

SearchWebServices.com has a good, short, article by Rich Seeley covering Gregor Hohpe speaking on Agile & SOA as a powerful combination.  Gregor, now with Google, is probably best known for his excellent work on enterprise integration patterns (site, book).

The article opens talking about Agile and SOA as apples & oranges:

Talking about SOA and agile development in the same breath may seem like comparing apples and oranges, says Gregor Hohpe, software architect at Google Inc., but from his point of view the terms go together like Google and search.

"Agile and SOA pair up to improve the alignment between business and IT," Hohpe told attendees at the Burton Group Catalyst Conference in San Francisco this past week. He was not being theoretical. He was talking about how Web services and applications are being developed by his employer, "one of the largest civilian computing infrastructures in the world."

The apples and oranges view comes from looking at SOA as being "an architectural style" that emphasizes how systems interact, while "agile" encompasses "a development approach" that emphasizes how people interact, Hohpe said. But in his view agile practices can help developers move SOA beyond theory.

The article goes on to point out how Agile’s emphasis on evolution, iteration, testing, learning as you go, and close customer collaboration, can help bridge the gap from SOA theory to real world deliverables.

This makes sense to me.  I always advocate starting small with SOA – the project (measurable return, low business risk), the team (good technicians, follow standards, work smart, continuous learners, influencers) and the infrastructure investment (leverage what you have, invest incrementally).  So, Agile concepts are definitely appropriate, particularly dealing with the unknown:

He urged anyone planning to start their first SOA project to not only start small but accept that they really won't know what they are doing. He urged them to accept that Agile principle "that you will know more at the end than you did at the start."

I also speak (over and over) to the importance of the “A” (architecture) in SOA for sustainable success.  Many readers of the article, and this post, might argue that Agile and SOA aren’t ‘apples and oranges’, or ‘Google and search’, but rather ‘oil and water’, because Agile skips architecture, and jumps right into design-code-test increments.

So, an interesting question then, becomes how is that architecture aspect reconciled?  Especially as you move beyond early experimentation.  How can you leverage agile development practices to implement solutions centered on an architectural strategy?  Assuming your staff isn’t loaded like Google’s. 

Right now, I have more questions than answers.  Nevertheless, I can’t help but think a healthy SOA (service model, shared infrastructure, and assembly patterns) is the perfect feeding ground for business solution development (assembly) using agile practices.  As well, I agree with Gregor, that embracing agile concepts for early SOA experimentation is smart.

I’ll definitely be doing some research and thinking along these lines.  If my schedule works out, I might even sneak out to Agile2006 for a bit next week. 

I’m very interested to hear what others think.  Have/Would you use Agile and SOA together?  How do you reconcile the ‘architecture aspect’?  Which do you start with?  As the article points out:

For the managers in the audience, he also stressed that both SOA and agile development take time for programmers to learn. He warned against the sink or swim approach where coders unfamiliar with SOA or agile practices are asked to start doing both at the same time.

Posted by brendamichelson in SOA • agile • architecture strategies | Permalink | Comments (11) | TrackBacks (2)

Last Friday, I asked