-
ever wonder how those graphs and predictions come to be?
-
why contribute? “JP Morgan’s CIO realized that support costs could be reduced by contributing the source code to the Linux community…important to JP Morgan, the company wouldn’t have to invest its own resources in maintaining an internal application”
-
quick rundown of popular scripting languages – php, perl, python, ruby and javascript in the context of “new era”. are folks using these for enterprise apps? does JVM runtime support make scripting language use more likely?
-
perspective on economics of cloud computing by Geva Perry, chief marketing officer of GigaSpaces
Archives for June 2008
SOA Stories, SOA & Event Processing in Ottawa, June 25-26, 2008
Next week, I’m headed up and left (northwest) to the SOA Consortium meeting in Ottawa, Ontario. We have a great line-up to help us explore two themes — “SOA Stories” and “SOA and Event Processing”.
During Wednesday’s SOA Stories day, we’ve invited speakers to share anecdotes, insights, lessons and battle scars related to real-life experience. I’m excited that Melvin Greer is returning to speak on SOA Hard Problems/SOA Spirals.
For Thursday’s SOA and Event Processing day, we’ve invited speakers to share experiences combining SOA and Event Processing to deliver business capabilities. Interestingly, the speakers are each adding another element to the SOA – Event Processing mix. Ed Lynch from IBM adds the element of BPM, while Bruce Henderson of Savant adds the mashup perspective.
After the invited speaker talks on Thursday, I’ll be moderating a roundtable discussion between invited experts and meeting attendees on the current and future relationship of SOA and event processing in the context of delivering business capabilities.
In their opening remarks, I’ve asked our roundtable leaders — Ed Lynch of IBM, Bruce Henderson of Savant, Ian Foster of Cisco and Greg Peres of Sun — to comment on any of the following SOA and event processing relationship aspects:
1) What are the business drivers and/or specific instances prompting organizations to combine SOA & Event Processing? What advantages are they gaining by using both, rather than just one?
2) What are the technology challenges in combining SOA & event processing? Is there a suggested implementation/adoption sequence? How does software/application development change?
3) What are the human/organizational elements associated with an event processing strategy? Are they similar to SOA – cultures of governance and collaboration? How does an event processing environment impact the daily lives of line and/or knowledge workers?
4) Is event processing yet another retro-technology strategy? How does/will event processing differ from pub-sub and/or straight-through processing techniques?
From there, we’ll take questions (and answers) from the audience. If you listened to our last roundtables, you’ll know the audience is very engaged, limiting my role to passing the microphone around.
Why am I sharing this? Two reasons. First, the meeting is open to the public. If you will be in the Ottawa area June 25-26, please consider joining us.
Second, if you’d like to share your perspective on the SOA-Event processing relationship aspects above, or submit a question to the roundtable, please leave a comment, or send me an email bmichelson at elementallinks dot com. Barring a recording calamity, podcasts from the above discussions will be available at the SOA Consortium Resource Hub.
[Disclosure: The SOA Consortium is a client of my company, Elemental Links. IBM, Cisco, Savant and Sun are not clients of Elemental Links, however they are sponsors of the SOA Consortium.]
links for 2008-06-19
-
Gates & Edison, constructive monopolists, pretty good tech, great reach–“What is his single most important legacy? The ability, through monopolistic business practices, to make Microsoft’s products global, de facto standards for business and consumers.”
-
must read post of actual project assessment — “There isn’t enough intellectual honesty within the FUBAR project. Managers reject or explain away bad news and real problems, looking instead for people who will tell them what they want to hear.”
-
“Instead of a strategy built around a consultant’s vision of ‘utility’ or…built around cheap or …built around excessive retail distribution and heavy advertising, they built their strategy around one girl saying to another girl, “wanna see my socks?””
-
hidden message (for any org) is mission & focus:”every great business is founded in a thesis, a statement of what should be true. It’s then the business’s job to go prove that thesis – in essence, the business becomes the argument that proves the thes
Does your SOA lack social skills?
That’s the question Hub Vandervoort, CTO of Progress Software, has been asking CIOs and EAs of late. Not to be confused with social computing, Hub is talking to organizations about their awareness and ability to form and retain relationships for the betterment of all parties. Why? Because at the core of SOA is federation. And federation requires cooperation.
Technology side federation is obvious. It is the assembly of disparate services, and underlying IT resources, into business solutions. Business side federation is less obvious, but enormously powerful. It is the cooperation of disparate business entities to generate value for all parties, including the end-consumer. In his eBook, Hub cites business federation examples from aerospace manufacturing, financial institutions and travel aggregators. In my own work, I often talk to this as business activity ecosystems.
This moment of federation-ecosystem convergence, diverted my short call with Hub on SOA and the Economy to become an extended conversation on the criticality of applying social as well as technical concepts for successful federations. Hub refers to this as “Socially Oriented Architecture” (eBook).
Although our conversation was far ranging, and occasionally tangential, I’m only going to focus on the core concepts here – contracts, governance, trust & commitment, and empowerment. To learn more about socially oriented architecture, check out the eBook and related webinar, and look for Hub on the conference circuit.
Contracts
As Hub was explaining socially oriented architecture, he spoke of some basic, but not simple, questions. The first:
“How do we organize ourselves as people so that we can in fact form cooperative arrangements?”
In a truly cooperative arrangement, no single party is in control. The parties establish a contract in which they specify responsibilities, timelines, communications, performance expectations, payments and penalties. That should sound familiar to practitioners of service-oriented architecture. This led to Hub’s second question:
“What’s the right sizing of the contract so it doesn’t encumber us with a bunch of decisions that really don’t matter, yet provides enough adequacy so that we can get an effective federation going?”
The answer to this question is all about service-orientation. A right-sized contract:
- focuses on “what” each party will do, rather than “how” they will do it
- includes performance expectations, payments and penalties
- specifies interaction style
- defines precise semantics
In respect to interaction style, Hub shared that the most equitable federations interact in an event-driven manner. Parties inform each other of progress and delays with the expectation the other party will respond appropriately. No single party controls the flow of work and information.
Governance
In a service-oriented architecture, governance mechanisms and organizations are put in place to monitor and enforce contracts. A governance approach works for single domain environments, but becomes problematic in a federation. This leads to another of Hub’s questions:
“What are the human dimensions to get people to interoperate together when there is no hierarchy stemming over those people?”
This question, first raised by Hub during a speaking engagement in Europe, led to collaboration with McKinsey during which the following “from-to” was developed:
“Moving from a world where the principle management tool has been hierarchy to a world where the principle management tool now has to become trust and commitment.”
Trust & Commitment
This brings us to the final question:
“How are trust and commitment established?”
Hub shared that you can only achieve a trusting relationship with good transparency. In a business context, this is the timely communication of relevant information. As an example, Hub cited a simple purchase order agreement with terms to send the buyer an advanced shipping notice (ASN) 14 days after the order is placed. If the seller wants to build trust, he should send the buyer notifications from each step of the order fulfillment process. Then, if an issue arises on the fifth day, both parties are equally aware and able to adjust.
Commitment requires agreement on a unit of value appreciated by both parties. In a business context, the most common units of value are time and dollars.
According to Hub, contracts need instrumentation in place to create a trusting transparent environment, as well as monetization to create a canonical unit of measure for commitment. Without these elements, a federation will not succeed.
Empowerment
Bringing the conversation back around to corporate IT, Hub described his vision for the future of IT organizations that embrace social constructs and shift to a trust and commitment management mindset.
“The real shift [for IT] is not to do what you’ve been doing in the past faster, but shift from being delivery mechanism to empowerment mechanism — truly democratized computing in a Web 2.0 sense. The end-user is always going to operate on the path of least resistance. Find tools that enable him to create his own solution… mashable desktops, data access through services…”
Another point that Hub and I converge on is the opportunity to learn about business optimization from how people “wire stuff together” and how they “react and respond to events”. To capture this information, the wired components and environment must include instrumentation and monitoring. Hub was quick to point out that IT needs to be careful not to institutionalize that learning in rigid, controlled applications.
Hub acknowledges that this is an “unsettling idea” and that perhaps the most unsettling part is ensuring compliance with regulations such as SOX, PCI, and HIPAA.
Wrap and Discussion
As our call ended, Hub spoke to the state of this work. Socially oriented architecture is in the idea, rather than implementation stage. The path to implementation would include education and practices on the case for federation, management change, contract structure and negotiation, organizational change, and technology implementation.
Hub mentioned some might consider socially oriented architecture “granola SOA for the casual pedestrian”, but he was quick to add that innovative times require new techniques.
I thoroughly enjoyed my conversation with Hub. As folks know, I’m most interested in exploring the connections between business, technology and people. As follow-on, I plan to take Hub up on his offer to learn more about the ‘case for federation’.
Discussion Questions – How Social is your SOA?
1. How federated is your SOA?
- Do business so
lutions (applications, processes, widgets, mashups) consume services from more than one domain? Are those domains within the control of your enterprise/agency? - Are the business capabilities your SOA provides part of a larger value chain? Is service-orientation or events used to interact with other value chain participants (partners, suppliers, regulatory agencies, customers)?
2. Does your basic service design include system and business instrumentation? How are those instrumentation events used?
3. Does your governance model rely on hierarchical relationships? Could it work in a federation with external parties?
4. Is your SOA designed with end-user empowerment in mind? Should it be?
[Disclosure: Progress Software is not a client of my company, Elemental Links]
A couple of thoughts on ‘Why Enterprise Architecture is a Joke’
A couple of weeks ago, Jeff Schneider wrote a post entitled Why Enterprise Architecture is a Joke. Jeff’s point wasn’t to ‘pick a fight’ but rather to point out some troubling issues associated with the practice of enterprise architecture:
1. Zachman pioneered, than stagnated. I believe that the single largest reason that EA is a joke can be linked back to the pioneer. This pains me to say, but many in our industry were patiently waiting for better stuff to come from Zachman and it just didn’t happen.
2. Bad Application Architects got promoted to be bad Enterprise Architects. Although this isn’t a universal truth, I’ve witnessed my fair share of it. Those who can’t architect do PowerPoint.
3. Silo Organizations promote Silo Funding. Many EA’s never had a chance. They live in organizations that fund everything according to business silo’s. Then, the EA is expected to bridge the silos with nickle and dime funding. Their inability to perform Herculean change (multi-channel, master data, cross-organizational BPM, master SOA services) has many of them designated as cops with no gun, just a good flashlight.
4. The Tooling Sucks. Modern EA tooling is complete pile of crap. It is designed and written by a generation who is out of touch with the needs of modern I.T. groups.
5. Unconnected Models. Expanding on #4, our models (and tools) do not sufficiently flow from one model to the next. Software development is often explained as a series of model transformations from concept to design to construction, where each stage adds additional fidelity. We currently have a huge hole between EA and the downstream constituents.
In the intended (non-combative) spirit of Jeff’s post, I’m going to add my 2 cents.
EA Frameworks
Similar to James’ response, I don’t often run into enterprise architects in commercial organizations that use Zachman. Certainly, almost all EAs are aware of Zachman, and appreciate his foundational work. But, many have come to the conclusion that Jeff has, the Zachman framework isn’t enough. It does provide a good frame to orient thinking, but producing and classifying documents does not make for an enterprise architecture.
Of course, this isn’t just an issue with Zachman, most enterprise architecture frameworks are artifact centric. As if producing the right documents and policies alone will result in a high performing, low technical debt, business aligned IT organization.
If you want an actionable enterprise architecture, you must go beyond artifacts. You need to create the environment (business capability to architecture strategy matches, architecture platform, portfolio planning & management, governance, talent development, etc) and relationships (business, IT leadership, delivery teams, operations teams) that directly contribute to the delivery of business capability. As I’ve said before, a sure way to failure is to view your architecture as an end, rather than a means.
Conflicting Measurement
Another I problem I see, that relates to Jeff’s “cops with no gun, just a good flashlight” metaphor is the disconnect between EA Governance and IT Leadership. EA teams are charged with policing delivery projects for compliance to the architecture. Among other things, compliance to the architecture should result in risk mitigation, investment productivity over time, business flexibility, reduced technical debt and skills optimization. However, many IT organizations (and their leaders) are measured on shorter term, operational aspects, such as on-time, on-budget, up-time, risk mitigation, etc. Given that people perform in accordance to how they are measured, regardless of the bigger implications, IT Management often trumps EA Governance to ‘get the thing in’.
These, seemingly arbitrary, bypasses of the enterprise architecture contribute to the ‘EA has no teeth/backing’ (is a joke) perception. While there are valid business reasons to give some projects a pass, it needs to be handled in a structured manner, as a waiver, accompanied by a plan to bring the assets into compliance, limit their proliferation and/or schedule their disposal.
While the waiver provides a formal acknowledgement that the project is out-of-compliance, enterprise architects can’t stop there. EAs need to educate IT management, delivery and operations teams on the value of enterprise architecture. And, during those conversations, EAs must listen to the needs of their constituents, in order to create a relevant, actionable enterprise architecture.
