• Blog
  • About
  • Archives

elemental links

brenda michelson's technology advisory practice

Archives for May 2006

Stop the Madness: SOA 2.0? No Thanks Online Petition @ Macehiter Ward-Dutton

May 31, 2006 By brenda michelson

Ugh! That was my reaction when I first read about "SOA 2.0". As Mark Little wrote "Giving an architectural approach a version number is crazy: it makes no sense at all!"

And please, do we need any more confusion on the relationship between SOA and EDA? I think not. And I’m not alone. Neil Dutton-Ward at Macehiter Ward-Dutton has created an online petition to "Stop the Madness". The petition reads as follows:

We’ve created this online petition because we’re dumbfounded at the attempt by certain parts of the IT industry to create and give weight to the term "SOA 2.0".

We and others have blogged about this already: Joe McKendrick, Mark Little, and Duane Nickull to name but three.

As Duane said recently: "Normally, when someone comes out with a new buzzword that doesn’t really have any substance, most people merely complain quietly and go about their business."

We would dearly love, just this once, for things to be different. Industry does not, at this point, need more confusion around SOA. SOA has real value, but industry at large is only just coming to terms with what it means and what it can do. Inventing terms like "SOA 2.0" might help some analysts and vendors make money, but overall, in the long run it damages us all.

In part, this petition is an experiment. Many people have discussed the power of the Web to aggregate and demonstrate the power of individuals: but it would be good to see if, through this simple web page, we could pressure the protagonists into backtracking on SOA 2.0.

I encourage practitioners who are sick of the hype, and looking for real information/ammunition to introduce/extend SOA in your business to click through this link, and sign the petition. (Just don’t double submit as I mistakenly did).

Filed Under: event driven architecture, services architecture, soa

Responding to James McGovern’s “Analyzing the Analysts: Brenda Michelson”

May 29, 2006 By brenda michelson

James McGovern has embarked on his own ‘analyzing the analysts’ series.  Today, he analyzes me.  James (good naturedly) takes me to task for breaking research mores.  He also poses some questions.  In this post, I attempt to respond.  James’ analysis is in italics.  My responses follow inline. Here goes:

J: First, let me get the bashing out of the way. She grew up as a Warrior and I am a Warhawk (Town rivalries) which means that I have to be highly critical of anything she does and therefore analysis will be even deeper seeking out holes than I would do for other analysts.

B: Talk about your past coming back to haunt you!  I was a “Warrior” 25 years ago.  I suffered defeat against the Warhawks in junior high basketball, but crushed them in high school tennis.

J: Second, my blogroll isn’t filled with very many women bloggers which means that even though she hasn’t acknowledged her duty, she needs to step up and get other women industry analysts to blog. It would be interesting if she could call up some women analysts from Gartner and Forrester and get them to realize the value proposition of having a two-way dialog.

B: True.  I did convince Patty to blog.  And, I’m not shy about the value of blogging for me.  But, I haven’t actively recruited for the cause.  In many ways, I think the large firms are best positioned to unleash a few good bloggers.  The salary investment for insightful, content rich blogging analysts could be easily absorbed.  And the return – community, meaningful conversation – is invaluable.  But, guilty as charged.

J: Third, she is one of the only industry analyst bloggers in the United States that isn’t babbling about product-oriented architecture and mentioning the latest greatest vendor she had a discussion with. Is she getting it twisted and think she is in the UK where analysts tend to only focus on customer problems?

B: I laughed out loud at this one.  I suppose, this could be attributed to my location at an outer edge of the US.  However, the real answer is pretty simple.  I want my research to help practitioners add value to their businesses.  That goes way beyond (the occasional) shopping for products.  This makes me a good community member, and consultant, but a less good (in traditional terms) analyst.

J: Fourth, her blog entries are very insightful. I suspect this is due to the fact that she was once an enterprise architect for L.L. Bean Seems like other analysts in the blogosphere never worked within a large enterprise and therefore have an outsider looking in perspective on our thought processes. I wonder if you could help out other analysts understand what business-driven EA (vs product-oriented EA) really means by not blogging periodically but doing a blogothon and drilling down deep every single day for the next three months.

B: Hmmm… Intriguing, but probably won’t cover my mortgage 🙂   In a perfect world, vendors or industry consortiums would sponsor (but not influence) the research time for the education and evangelism you refer to.  Heightening awareness, sharing knowledge, and encouraging community interaction will strengthen everyone’s work in the end.  I’ll do my best to increase my blogging frequency, without completely diluting the content.

J: Five, your boss always talks about innovation but I have never seen you discuss this topic. Yes, this word is minimally abused and definetely overloaded. Many EA practitioners believe that EA is all about transformation which is distinct from innovation. Maybe you could tell us what innovation for EA is all about?

B: Sure.  I can provide my take on Innovation and EA in a future post.  They aren’t mutually exclusive.

J: Six, how come you don’t speak at conferences? I am tired of the mindless dribble that comes from other industry analyst firms. It is so high-level that I have to pretend I am Bill Clinton lighting a big one but not actually inhaling. What would it take for you to speak at an upcoming Infoworld conference? I am sure Jon Udell can hook you up.

B: Good question!  Perhaps my style of industry analysis is an acquired taste?  I will be speaking at CMG2006.  I’m in the process of lining up a couple more.

J: Seven, it’s ok to talk about personal things every once in awhile. What do you drive? Where do you vacation? What was the last book you read? Could you tell us what other industry analysts you have engaged in meaningful dialog with before (I know you and Stephen O’Grady have talked but who else?

B: Ok, prepare to be under whelmed.  010_08aSummer vacations are lakeside (and trailside) here in Maine.  Typically in the Rangeley area.  I’m currently reading The Art of the Start, Open Sources 2.0 : The Continuing Evolution and Influence: Science and Practice (4th Edition).  Two of my favorite books are Einstein’s Dreams and Orbiting the Giant Hairball : A Corporate Fool’s Guide to Surviving with Grace.  Steve is one of my favorite industry analysts.  Besides work, we have common interests in Maine business development and the Red Sox.  I’ve also enjoyed conversations with Jon Udell, my longtime friend Beth Gold-Bernstein, Sandy Rogers, Anne Thomas Manes, and Ron and Jason.  Admittedly, I don’t spend a lot of time out on the analyst circuit. 


J: Eight, we both have a vested interest in SOA and Portals but what would it take to convince you to start doing a research report on how enterprises can start embracing web 2.0? We know that other analyst firms are clueless to web 2.0 and you will have a headstart of at least six months before they finally get their ah-ha moment.

B: No convincing necessary. 

J: Nine, I’m in a sharing mood. What would it take for you to come and visit our enterprise and do a case study on how we do architecture governance or even on practices we use to construct our SOA?

B: Not much.  The keys are access to the right people, and navigating the publication approval process.   

J: Ten, does your boss know that you actually put references to non-seybold research in your reports? This is even more transparent than what any other industry analyst firm has ever done. Maybe the others will continue their practice of plaigarism and simply stay status quo but you need to talk about why you do this and encourage other analysts in the blogosphere to start doing the same. Transparency builds trust…

B: Yes, Patty knows.  I’m not aware of any plagiarism.  I read a lot, and presenting as complete a picture as possible, with attribution is in the best interest of my readers, and those I read. 

Filed Under: Elemental Links, social

My New Business-Driven Architect blog @ ebizQ

May 18, 2006 By brenda michelson

This morning, I launched my new Business-Driven Architect blog at ebizQ. In the introductory post, I use a question-driven format to provide context on business-driven architecture and architects.

In addition, I ask and answer the following:

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.

That leaves just one outstanding question:

How will I fit in all this writing?

I’m working on it…

Filed Under: business-driven architecture, social

Global Integration Summit, Boston May 22-24

May 17, 2006 By brenda michelson

Next week I’ll be attending the Global Integration Summit in Boston, Monday May 22 – Wed May 24. My attendance is centered on Tuesday’s Integration Solution Showcase – I’m on the review panel.

The solution showcase pits SOA/integration vendors against each other to solve a live integration problem in a fixed time frame. Getting to “the answer” is only part of the criteria. Each participant must also share “the how” and then “sell their solution” to the conference participants, and the review panel.

Here’s the Problem Description taken from the GIS site:

The purpose of the Showcase this year will focus on the challenge of integrating standards-based web services and using orchestration to provide business flexibility. We will be solving a problem for Anybank who is in the business of underwriting home mortgages. Our challenge will include:

  • Parsing and interpreting standards based Web Services
  • Discovering and utilizing a vendor’s Web Service
  • Choreographing Web Services to enable rapid business change

The challenge will be to create an orchestrated application that implements a part of the business process of processing a mortgage application. You should be able to automate the following process steps.:

1. Start.

2. Receive a mortgage application via a Web service.

3. Interface with an external agency to verify data on the application via a Web service.

4. Run an internal Web service to determine a proposed interest rate.

5. Update the Mortgage via a Web service.

6. End.

7. The real challenge begins after demonstrating your basic composite application when you will demonstrate how you would change the application to modify step 4 to call the original or a new Web service (with similar content but different data representation) based upon data values verified in Step 3.

In addition to the Showcase, I intend to take-in some conference sessions on Monday afternoon and Wednesday. Topping my list is Annie Shum’s Wednesday afternoon session Leveraging city planning and other social metaphors to guide SOA – Why Meta Matters.

If you are attending the GIS and want to connect, comment here or send me an email: bda at elementallinks dot com.

If you are a vendor participating in the Solution Showcase, I’ll be happy to meet with you on Wednesday – after the votes are in!

I intend to blog from the GIS, and will definitely be writing about it for the PSG Service.

Filed Under: circuit, integration, services architecture, soa

Observations from the Field – The Hard Part of SOA

May 5, 2006 By brenda michelson

Where have I been? It’s been over a month since I posted. I’d wish I could say I’ve merely been enjoying the first springtime in Maine I’ve witnessed in the dozen or so years I’ve lived here. But, in actuality I’ve been working – consulting, chatting with architects and lead technologists, writing, reading, tinkering and thinking. It’s the last one (thinking) combined with a period of silence that used to simultaneously intrigue and frighten my old (awesome) team at LLB. It was hard to predict the outcome of such a cycle, but it was bound to be interesting! At the moment, even I’m not sure what will transpire, so I’ll refrain from wasting more space on that here (for now).

In the meantime, I want to share some information and insights I’ve collected over the last month. Instead of dumping everything into one post, I thought I’d start with an excerpt from the Observations from the Field: SOA report I just wrote for PSGroup.

In this excerpt, I share the “Hard Part of SOA” as identified by enterprise practitioners and lead thinkers/technologists (not marketers) at application infrastructure vendors.

The illustration I’ve included is one I first drew for a SOA workshop gig in 2004. I’d be curious if readers see the relationship between re-use and granularity differently.

Since real-world insights are invaluable, I invite enterprises to share their SOA tips, concerns, and stories with me. In turn, I’ll share that information back to the broader community. Together, we can cut through the hype, and develop pragmatic practices for SOA success.

Excerpt: The Hard Part of SOA

Enterprise architects and technical leaders consistently state the hardest part of SOA isn’t the technology. Rather, the real work is in service definition, semantics, and establishing a SOA program.

1. Service Definition

Many enterprises find it difficult to determine the correct bounds (job and tasks) and granularity (collaborations) of business services. Correctness is viewed in terms of both re-use and agility. Business services should be reusable (shared) within a line of business, across lines, and in some cases, at the enterprise level. Business services should be easily changeable (replace, augment, compose) to meet business demands.

Enterprises have erred equally on creating services at too fine a grain, and too large a grain. Erring on the fine-grained side still allows for re-use, through service collaboration, but creates performance inefficiencies to perform actual work (bounds). Erring on the large-grained side creates application- or use-specific services, rather than common business services.

Business Service Re-Use Diagram [click on diagram to enlarge]

Elementallinks_service_reuse

This illustration shows the general relationship between granularity and service re-use. As service granularity increases, the opportunity for re-use of the resulting service decreases. However, what’s important to note is the reliance on collaborators when creating a large-grained service. A large-grained service, such as a process-oriented service, should be composed of multiple function and information-oriented services. The proper use of appropriately bounded (defined) collaborators is the re-use payoff.

Industry Specifications. Architects most confident in their business service definition have been able to leverage industry-specific specifications, such as the Open Travel Alliance (OTA). OTA specifications include schemas and WSDL implementation guidelines for common travel-related interactions, such as Request Rail Availability.

Unfortunately, industry specifications for true service interactions, rather than information hand-offs, are the exception rather than the norm. In most cases, architects and business analysts are relying on
service definition practices from SOA technology and/or solution providers, or adopting best practices from experience, gut feel, and a wide range of published methods, including PSGroup’s Service Discovery.

Lack of Methodology.
What’s missing—and desperately needed—is a publicly available, cohesive, services definition methodology. Cohesive doesn’t refer to degree of documentation. [I believe a methodology should contain the right amount of methodology to accomplish the task, no more, no less.] Rather, with the word “cohesive”, I am referring to the service definition activities that span business modeling, analysis, and design. You find a service (and the need for it) during business modeling. You define and refine the service during analysis. You further refine and provision the service during design.

In such, the business definition of a service is derived independent of technology implementation—current or future. As notation and tooling are used to transition the business service definition to technical implementation, the business intent must be retained.

Since the emergence of a good methodology happens over time, from real-world experience, I encourage practitioners to share their tips and challenges publicly, and join or create practitioner-led forums to advance real-world SOA.

2. Semantic Understanding

For humans, machines, and the combination, semantics has always been a challenge. While it is relatively easy to receive information (conversation, message, data exchange) it is not always easy to discern the sender’s true meaning. For example, when the word “customer” is used, does it mean end consumer, prospect, or purchaser?

As information exchange between applications and businesses became prevalent, industry and company dialects were defined to assign common terms, syntax and meaning to information elements. Given the initial purpose (technical integration) of these terms, the definition and administration has largely been the purview of technologists (geeks). As such, many of the terms are cryptic, derived from the application and information sources, rather than a true business dialect.

With SOA, the need for semantic understanding becomes even more pronounced, because of the multitude of service interactions, and the self-describing nature of service-oriented languages for service descriptions, contracts, policies, and orchestrations.

Use Business Terms.
Similar to the service definition (above), semantics must be expressed in business terms. These terms must be recognized and understood by both business and technology professionals and machines, within an enterprise, and often between enterprises.

Most architects are approaching the challenge of semantics incrementally. A first priority is to achieve a common language between human parties in the enterprise, to enable proper business service definition.
Another is to adopt a common XML dialect to enable semantic interoperability between services.

A common practice is to describe interfaces and message payloads with a common XML dialect, and leave the underlying providers (applications, data stores) in their current formats.

The adoption of industry standard dialects varies by enterprise. Some enterprises adopt industry standards such as ACORD for insurance, throughout the enterprise. Others limit the adoption to customer- and partner-facing services. A common complaint from architects is the industry dialects are overly complex. And the problem worsens as functional dialects (human resources, banking) are added to the mix.

Vendors agree. The semantics problem is very difficult to resolve. While most offer support for industry dialects in their SOA products, none have tackled the big semantic problem. Although the problem is difficult, it can’t be ignored. To ease your way, be sure to define and/or adopt a common business lexicon for semantic compatibility of services, applications, events, processes, information stores, and of course, people.

3. SOA Program

The mission of an SOA program is to articulate and execute an SOA strategy that makes sense for your business. Common activities include evangelizing SOA, setting and enforcing standards (technical, methods), selecting application infrastructure and tooling, building out common (system-oriented) services, finding and conducting pilot projects, and stewarding the service catalog.

Architects, technical leaders, and business solution project leaders say the biggest challenge in developing a SOA program is balancing the natural tension of executing business projects (today, on-time, on-budget) with the need for architectural integrity.

Obviously, the simplest thing to do is give your architecture team a head start. Fund, staff, and start the SOA program three to six months ahead of the first business project that needs it. The shorter the head start, the less critical that first business project should be.

Barring the luxury of a head start, build iteration, tolerance, and refactoring into the execution of your architecture and business project. Tips from the field include:

•Re-Use. Be smart about re-use mandates. While every service has re-use potential, focus initial development efforts on business and infrastructure critical services. Everywhere else, use good design practices—well-defined interfaces, separation of concerns—to allow for non-invasive replacement of “non-enterprise class”
assets.

•Increments.
Plan and deliver your SOA environment—practices, tools, technology, and infrastructure—incrementally. Plot your plan to balance business project delivery and architecture delivery. Better to build an incremental architecture, than a bottleneck, or bypass route.

•Refactor.
For tolerant re-use and incremental architecture, you must plan and allocate time and resources to refactor and re-release code/assets.

•Simplify.
Trust your architect instincts. Think about the standards, technology, and products you need in a service-oriented manner, and then map options to them. Don’t buy a box of SOA. Leverage tools and practices you have in place today.

•Communicate.

Early and often.

Filed Under: services architecture, soa

Brenda M. Michelson

Brenda Michelson

Technology Architect.

Trusted Advisor.

(BIO)

  • Email
  • LinkedIn
  • RSS
  • Twitter

Recent Posts

  • Experts Sketch
  • PEW Research: Tech Saturation, Well-Being and (my) Remedies
  • technology knowledge premise
  • The Curse of Knowledge
  • better problems and technology knowledge transfer

Recent Tweets

  • “…where the process of drawing itself can take us. We can follow a suggestion, a squiggle, shadow, or smudge, and s… https://t.co/oRg0x2LoXG November 30, 2022 5:05 pm
  • On the waiting list for Post, join me (on the waitlist) via https://t.co/U8wYK707f6 November 24, 2022 4:17 pm
  • Meet the longtime librarian being honored at the National Book Awards : NPR https://t.co/S44VQeJg83 November 13, 2022 2:51 pm
© 2004-2022 Elemental Links, Inc.