elemental links

Smart Roads, Bridges & Grids call for Smart Event Processing

It wasn't that long ago when the typical "sensor" (and perhaps only) use case for event processing was RFID.  I certainly used that example -- TVs escaping the warehouse -- if I recall correctly.  Oh, and more recently, the interesting, but non-mainstream case of cow containment.

Well, that's all drastically changing with the emergence of "smart" public infrastructure - roads, bridges, grids, waterways and the like -- accompanied by a hefty "shovel ready" stimulus package.  (Shovels to build the infrastructure, not for processing the events!)

"Imagine highways that alert motorists of a traffic jam before it forms. Or bridges that report when they're at risk of collapse. Or an electric grid that fixes itself when blackouts hit.

This vision -- known as "smart" infrastructure -- promises to make the nation more productive and competitive, while helping the environment and saving lives. Not to mention saving money by making what we've got work better and break down less often."

As I was reading the Smart Roads. Smart Bridges. Smart Grids. feature in the WSJ, I couldn't help but notice all the event processing scenarios and patterns.  As you would expect, all the scenarios start with sensors and instrumentation and involve event (instrumentation) transmission, detection and processing.  The order, frequency and end actions of transmission, detection and processing vary by scenario.

What follows are excerpts from the article in the domains of smart transportation and grids and my associated event processing observations.   The emphasis is mine.

SMART TRANSPORTATION

The article describes the smartening of transportation as evolving from data collection and visibility all the way to "the ultimate science-fiction vision -- roadways that control vehicles and make "driving" unnecessary -- isn't that far in the future. Mr. Lamba says IBM is in discussions with a small city to build a completely automated transportation system that would include 3,000 remote-controlled vehicles. The company won't identify the city or give any other details."

Being a pragmatist by nature, I'll leave the science fiction to others, and stick with the nearer term: 

"One promising avenue: real-time information about road conditions, traffic jams and other events. People can increasingly find that data on the Web with services such as Google Maps. But the next generation of technologies promises to get that news -- and even more detailed information -- directly to drivers in their cars. Armed with that information, drivers can make better decisions about which routes to take -- which can have a big effect on traffic."

Instrumentation for tracking, simple calculation and real-time visibility -- roadside "dashboards" for decision-makers (drivers)

"The first step is collecting better data about traffic flows. The California Department of Transportation, or Caltrans, has installed radio receivers along several freeways in the San Francisco Bay area that read the electronic toll tags in passing cars. Using that information, Caltrans can track the speed of individual vehicles and determine the travel time from one point to another. Then those times are posted on electronic road signs. (Caltrans officials say they don't keep track of personally identifiable information from the tags, to protect privacy.)

Eventually, the data from the roadside sensors could help traffic controllers guide drivers to other travel alternatives: Is a bus or a train faster than the freeway? To that end, Caltrans and the Bay area's Metropolitan Transportation Commission are testing three electronic signs south of San Francisco. Along with freeway travel times, the signs show scheduled travel and arrival times on Caltrain. Drivers can see if they'd be better off getting out of heavy traffic, heading to a station and catching a train.

In the future, planners intend to show real-time train travel and arrival times, as well as the number of available parking places at the nearest station."

Adding prediction and real-time actions -- adjusting traffic signals

Another way to ease congestion is to predict traffic jams before they form. IBM has developed software that can examine current traffic patterns and foresee congestion up to 45 minutes ahead. The system, being tested in Singapore, has proved to be about 90% accurate in predicting the volume and speed of drivers in the central business district. The information is then used to adjust 1,700 sets of traffic lights to smooth the flow of traffic.

"We say that real time is too late," says Naveen Lamba, leader of IBM's global intelligent-transportation efforts. "You have to see into the future to minimize the impact of what's going to happen."

[Aside: "Seeing the future", or in their terms "Querying the Future" is the mantra of SQLStream, a real-time business intelligence player with a new streaming engine offering built on 2003 Standard SQL.]

Instrumentation for exceptions (accidents), correlation (time, location, severity), notification and dispatch (responders)

"Some researchers are attacking another source of traffic backups: accidents. Trimming the time it takes to clear the roadway after a crash would help ease congestion. Reducing the number of accidents would be even better -- lowering injuries and fatalities, as well as costs associated with accidents.

Enter a concept called vehicle infrastructure integration, or VII. These systems would let roads, traffic signals and vehicles talk to each other, and share crucial information automatically, by using a range of technologies -- GPS navigation, wireless communications, advanced sensors and onboard computers. For instance, a car in an accident could send out an automatic message about the time, location and severity of the crash to receivers along the roadside, which would then automatically dispatch emergency vehicles."

Bringing the 'dashboard' to the driver's dashboard

"Caltrans is testing a left-turn signal that flashes a big red arrow with a slash through it when it detects a vehicle is approaching rapidly from the opposite direction. For now, the arrow flashes on the signal itself; the goal is to have the warning beamed directly into the turning vehicles."

SMART GRID

"The U.S. electricity grid is arguably one of the most important technological achievements of the 20th century. And yet, it's pretty dumb. Power flows one way, but the utility gets back very little information about how it's being used. And the grid is poorly set up to handle power coming in from alternative-energy sources, such as wind farms."

Instrumentation for tracking, simple calculation and real-time visibility -- "dashboards" for decision-makers (providers and consumers)

"The first step is installing advanced electric meters that send a steady stream of information back to the utility. They make it possible to read meters remotely and to determine more precisely the location of power outages. And they can give customers a more detailed view of their electricity use."

Adding "what-if" capabilities to the consumer's dashboard

"Beginning next month, Houston-based CenterPoint Energy Inc. is preparing to install more than two million smart meters over five years. During a two-year test of the technology, consumers were able to call up a Web portal showing the energy consumption of the home's major appliances. Consumers also could calculate energy bills in different situations: What would be the effect of keeping the house at 75 degrees in the summer instead of 65? What adjustments would be necessary to keep summer electric bills under $200?"

Instrumentation for exceptions (outages), notification and near real-time response

"A smart grid would even be able to partly heal itself. Today, when a storm drops a tree branch on a power line, utilities typically have to rely on customer calls to locate the damage and assess the scope of the outage. CenterPoint is testing special sensors and switches that sit alongside power lines and detect sudden changes in the amount of current through the wire. The utility then can quickly route power around the break, restoring electricity within seconds to a large part of the blacked-out area and limiting the number of households affected."

If you lived here in Maine, that last one would be particularly enticing.  Camping in your den loses it's allure by the 10th day.

Of course, the smartening of our infrastructure also requires innovation in sensor technologies.  While not "event processing" per se, I found the following from smart bridge section interesting:

"The University of Texas at Austin received a grant to create wireless networks of sensors to monitor cracks in existing bridges where the failure of a single piece could bring down the entire structure. Because getting power to the sensors can be a problem, the group is studying how to use the vibrations of the bridge to generate electricity for the devices. It's also working on devices with enough computing power to analyze the stream of data and send alerts when potentially serious damage occurs.

Looking beyond traditional sensor technologies, another grant went to a group led by the University of Michigan. The group is developing smart materials that can be built into or applied to key bridge components to detect and measure changes. For instance, researchers are working on a sensing "skin" that can carry electrical or magnetic signals to give a two-dimensional picture of how the structure responds to different stresses, says Jerome Lynch, an assistant professor at the university."

If these excerpts intrigue you, I highly recommend reading the article.  If you are thinking, "interesting, but we aren't in the infrastructure building, monitoring or use business", then I ask you to think about portions of your business that can benefit from instrumentation, monitoring and rapid response in order to mitigate risk, seize opportunity, and/or help you intelligently stumble on the future.

Health IT Stimulus Check to Spend? Check out the Practical Guide to SOA in Healthcare

Earlier this week, while I had my head in the clouds, my colleagues at the SOA Consortium released another podcast from our Santa Clara meeting.  This one features Ken Rubin, Chief Healthcare Architect, EDS Federal Healthcare Portfolio, presenting a pre-release overview of the Practical Guide to SOA in Healthcare.

I had an opportunity to participate in the review of this document, so I was excited to book Ken at our meeting.  No surprise, my favorite parts of the document and the presentation are the healthcare specific artifacts and anecdotes.  Glancing below, you'll see the reference architecture, which is actually quite detailed.  To drill in, download the Practical Guide document.  And of course, check out the podcast.  What follows is swiped from my post on SOA Consortium Insights:

 

The Practical Guide to SOA in Healthcare, an output of the Healthcare Services Specification Project (HSSP), is a collaborative work of the OMG Healthcare Task Force & Health Level 7 (HL7). The goal of HSSP is to develop SOA specifications for health, specifically defining healthcare business services to enable interoperability between organizations across the health domain.

While not a standard, the practical guide provides context and guidance for healthcare IT organizations and professionals considering SOA. Using a fictitious example, the practical guide presents an 8-step process to establish a healthcare SOA, from enterprise architecture through sustainment, and includes valuable lessons learned.

During his talk, Rubin spoke of the current state of global healthcare, and anticipated changes with the new U.S. administration and Health IT programs. Walking through the practical guide, meeting attendees were keenly interested in the healthcare function to service mapping and the reference architecture. Rubin emphasized that the reference architecture is a starting point for people to think about the problem, and extend and amend for their own situations.

Throughout his presentation, Rubin took questions from attendees on SOA adoption by healthcare market segments, medical and legal implications of a services approach, such as provenance tracking, application provider appetite for SOA, credential management and the applicability of the guide and impending on standards outside of the healthcare domain.

To listen to an audio recording of Ken Rubin’s presentation and view the slides go here.  For more information on the Practical Guide for SOA in Healthcare initiative, and to download version one of the guide, please go here.

 

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

Unintentional Cloud Watching >> Cloud Computing for Enterprise Architects

Despite my best intentions, I find myself watching the (insert meteorological pun) cloud computing space.  Only time will tell if my cloud watching is attention well spent.  If the cloud is indeed "the future of the Internet", then yes.  If the cloud is merely a repackaging of everything that we already do, then no.  Most likely, the cloud's promise falls somewhere in between, landing closer to the future than the past. 

Added to this (more likely than not) significance, are parallels with my own writings, work and interest areas (current and past), including architecture realization through blending strategies, the power of service grids, the ceding of applications to business capabilities, the morphing of boxes to platforms, and (forthcoming) creating an active information tier.

Since I haven't published blog posts for two of these concepts, let me digress for a moment.

On "the ceding of applications to business capabilities", if you have spent any time in the same room with me during the last 5 years, you've undoubtedly heard or seen some version of the following quote from me:

"By nature, SOA enables an enterprise to compose business services, business events, rules and policies into business processes and interactions that actually match the intent of the business strategists and process owners.”

The first iteration (Jan 2005) read like this:

"...SOA will be the springboard that propels IT organizations away from traditional application development toward delivering IT instantiations of business scenarios, or business scenario development.  In business scenario development, IT business solutions will be compositions of services, business events, and business processes matching the interactions of your business—with customers, partners, employees, and regulatory agencies—in the support of commerce, collaboration, and information exchange."

On "the morphing of boxes to platforms", what follows is a slide I created for last summer's ComputerWorld Data Center Directions conference.  I was asked to do a mini-presentation on server management, but as you can see, I started with a broader view of "boxes morphing to platforms" and then spoke of related management implications.

Oh, and while I'm digressing, the service grid excerpt from the introduction to my April 2006 paper on StrikeIron:

"...the intersection of service-oriented architecture (SOA) and software-as-a-service (SaaS)—the service grid model.

In a service grid, hundreds or thousands of services from a multitude of providers are available for enterprise consumption. These services, like all services, may perform a simple task such as information retrieval, or execute a complex business process.

While the service grid model provides a powerful vision for business and IT agility, it is quickly daunted by the complexities of forming and managing a large volume of micro-relationships. For a service grid to thrive, third parties are needed to connect buyers and sellers, manage service levels, meter usage, consolidate bills, and collect and disburse payments."

Despite these obvious parallels, as I was working on my 2009-10 research/writing plans, I knew it wasn't possible to cover everything I'm interested in, so cloud fell into the "interested, but no time" category.  Plus, I figured (rightly) that everyone and their dog would be covering "all things cloud" this year.

Long story, longer...After attending the Open Group's EA conference and Cloud Computing Summit, I realized that as an enterprise architect type, I couldn't (and shouldn't) escape cloud watching.  And since I'm watching, I might as well share what I see.

This said, my cloud watching plan (more or less):

1. Cloud watch with the lens of an enterprise architect type practicing business-driven architecture.
2. Share information and observations on selected (#1) cloud computing developments and activities.
3. Highlight interesting, relevant (#1) works of the cloud computing community -- providers, consumers and consortia.
4. Add to the conversation, but not engage in "yet another" syndrome. (No "What is Cloud Computing" piece from me)

Oh, and to be clear, this is additive to my plan.  I'm far from done with SOA, event processing, business architecture, enterprise architecture, active information and the business-IT relationship.

If you'd like to chat about cloud computing for enterprise architects, or any of my other coverage areas, leave a comment or drop me an email.  Please, no "story idea enclosed" emails.

Around the web with TOGAF 9 (+ArchiMate)

Ok, I confess, I've had the near 800-page TOGAF 9 document for a couple weeks and find myself with several hundred pages still to read.  So, this post is not further commentary from me on TOGAF 9, rather a collection of TOGAF 9 (and related) links and resources you might want to check out.

Before I go further, I should set some context by reiterating my comment to Mark Griffin on enterprise architects, architecture frameworks and ivory towers:

"I share your concern that EA can be (sometimes deserving) viewed as an ivory tower. I'm encouraged by the modularity of TOGAF 9 and the related messaging from the creators that EAs should pick and choose the TOGAF steps, artifacts & practices that make sense for their business situation. Used this way, TOGAF (and any other framework) becomes a tool rather than a mission in itself.

For the reasons you mention, I've never been an ardent framework follower. Too often that leads to excessive documentation and little implementation. I'm more of a "sampler", on the look out for artifacts, guidance, practitioner ideas I can apply to my work in the context of delivery.

As I dig into TOGAF, I'll be testing for value within my "sampling" point of view and sharing those findings for real-world folks like you."

TOGAF 9 Overviews & Commentary

Nick Malik: A first look at TOGAF 9.0

The ever thoughtful Nick Malik shares his first impressions of TOGAF 9:

"I’m not a certified TOGAF practitioner.  That caveat aside, I am someone who has studied multiple frameworks, and created an architectural framework, so I can draw on a good bit of experience when reviewing one.  I spent some time reviewing the prior version of TOGAF, and my first impression of the new version is this: Substantial and Deep Improvements.

The new version has a comprehensive model for the content, insuring that the stakeholders for architecture have separate sections of the framework dedicated to each of their varied concerns.  This makes navigation and adoption considerably easier.  In addition, substantially new content, along with new models and a richer set of descriptions, have been added.  The new framework is more readable and more usable than it’s predecessor.

The focus of TOGAF 9.0 has been sharpened, drawing the distinctions between different concepts and activities into the light.  This was needed for strategic architecture to be successful in to TOGAF model.  The terminology is more consistently described and used, and the attention to detail is refreshing.

The TOGAF is, and probably always will be, a work in progress.  It is a community effort, and the community that worked on this version have expended considerable effort.  That effort shows.  I really like where this framework is going.

Here is my call to action: for the first time, I’m willing to say this: The TOGAF is enterprise ready.  If your organization does not have a framework, or if you are using Zachman with some home-grown methods, I recommend that you serious consider TOGAF 9 for adoption."

Nick's post continues with a discussion of specific things he appreciates and opportunities for improvement.  If you are interested in TOGAF 9, this is a must read post.

Mike Walker: TOGAF 9 Release & Impressions

Mike does a nice job of describing the TOGAF 9 enhancements, followed by commentary on what architects will care about and what needs improvement.  Mike's bottom line:

"Whether you are using TOGAF in your organization or not TOGAF 9 is definitely a framework you want to evaluate. I didn’t find anything that was negative about TOGAF 9. Even though there are some gaps and some areas that could be more developed the bits that are refined were really good. Keep in mind that the focus for TOGAF is still mostly at the process level and dealing at a high level of abstraction should be expected."

Dana Gardner: TOGAF 9 Podcasts

Dana has a lot of TOGAF 9 coverage.  In addition to some overview posts, he published podcasts with Open Group's Allen Brown and of an architect thought leader panel session he moderated at the EA conference.  [I also live-blogged that session.]

Michael Poulin: TOGAF 9 is short on SOA

Of course, not all is sunshine and puppies.  On ebizQ, Michael Poulin offers an in-depth 3-post series on why TOGAF's new ADM guidelines for SOA fall short.

"For the whole last year we waited for new TOGAF version with high expectations regarding proper positioning SOA in the Enterprise Architecture. Being a TOGAF 8 Certified Practitioner and a 'SOA guy', I was, probably, among the most impatient ones. I mean positioning of Service Orientation (SO) rather than SOA, though. The TOGAF 9.0 release has finally brought a lot of very right words about business nature of SO but still lacked the right order of those words in a few crucial places.

While not mentioning that TOGAF 9.0 does not refer any other SOA standards (from OASIS or OMG), I am mostly dissatisfied with three areas of 'Using TOGAF to Define & Govern SOAs' chapter:

• representation of the essence of service
• Service contract
• SO role in ADM"

What I've yet to run across is any commentary on the new ADM Security Guidance.  Could this be another sign that enterprise architects prefer to remain "blissfully ignorant" on security?

I'm sure there are many other insightful TOGAF 9 posts that I missed.  Please pass along those links in the comments.

 

TOGAF 9 Resources

The Open Group Bookstore: TOGAF 9 Pocket Guide

I found this pocket guide to be helpful.  It gives you an introduction to TOGAF 9 and helps you determine applicable areas to explore further.   A pdf of the pocket guide is free to Open Group members.  For the rest of us, a hardcopy of the pocket guide is available for $26.  I received my pocket guide for free at the recent conference. 

"This Pocket Guide is based on TOGAF Version 9 Enterprise Edition. It gives a concise introduction to TOGAF 9. What's more, it's authoritative, with material derived from The Open Group's TOGAF 9 documentation and contributions from members of The Open Group Architecture Forum. The audience for this Pocket Guide is enterprise architects, business architects, IT architects, data architects, systems architects, solutions architects, and senior managers seeking a first introduction to TOGAF."

TOGAF(tm) Version 9 - Non-Member Download

"You may download TOGAF Version 9 under a free, personal, 90-day Evaluation License; and you may then go on to use it internally under a free, perpetual, Corporate License or a free, perpetual, Academic License, if you wish. Alternatively, you may take out an annual Commercial License."

ArchiMate & The Open Group

In related enterprise architecture activity, according to the January 2008 ArchiMate newsletter (pdf) ArchiMate and The Open Group are Joining Hands:

"The board of the ArchiMate Foundation and the board of The Open Group have expressed their intentions to adopt ArchiMate as an independent standard for enterprise architecture modelling and analysis under the aegis of The Open Group.

When the ArchiMate Foundation was initiated, international adoption of ArchiMate was expressed as one of the most important goals, the reason being that standards such as ArchiMate need international adoption to have impact and remain viable.

The above steps with The Open Group will pave the path towards international adoption.  These steps have come sooner than expected. The Open Group themselves were searching for a good standard for enterprise architecture modelling and analysis. ArchiMate will fill in this need.

The Open Group also governs TOGAF (The Open Group Architecture Framework). TOGAF mainly contains methods and best practices to create an enterprise architecture. ArchiMate complements this, as it is a language for enterprise architecture models. Thus, TOGAF and ArchiMate can work hand in hand or be used independent from each other. Both TOGAF and ArchiMate will remain independent standards so user organisations have a choice what to adopt.

At this very moment, The ArchiMate Foundation, The Telematica Instituut and The Open Group are working out the best way to hand over the rights and obligations. Current ArchiMate license holders will be informed via the ArchiMate user council."

If you are like me, you might be thinking "I've never heard of ArchiMate".  And "isn't modeling the purview of the OMG?"  From the ArchiMate site:

"ArchiMate is a modelling technique ("language") for describing enterprise architectures. It presents a clear set of concepts within and relationships between architecture domains, and offers a simple and uniform structure for describing the contents of these domains."

To learn about ArchiMate, check out the language primer (pdf) and this interactive resource tree.  If you currently use ArchiMate, drop a comment or email on usage scenarios and your impressions.  I discovered ArchiMate at the conference and plan to investigate further.

 

[Disclosure: The Open Group is not a client of my company, Elemental Links.  However, the Open Group did invite me to their recent EA Conference & Cloud Computing Summit and provided my on-site accommodations.  The OMG, via their management of the SOA Consortium, is a client.]

Fortune: Jim Collins on turning crisis into opportunity

Since I haven't harped/amplified on the critical role of talent in tough times in awhile, I thought I'd highlight a couple of tidbits from a recent Fortune interview with Jim Collins on How Great Companies Turn Crisis into Opportunity.  The sub-head sums it up pretty well "In troubled times a business needs enduring values, the best talent, and an ability to "zoom out" an see past the chaos in front of it."

And yes, I suppose with my mantra of taking a holistic view and then acting pragmatically, I could just as well emphasize the "zoom out" message, but it was the following excerpts on talent that caught my attention. (emphasis is mine)

Fortune: So what did they [enduring companies] do to get through the tough times?

Collins: ...The other thing worth mentioning is that these companies, when they went through the Depression, really understood that it was the caliber of their people that would get them through. If there's a storm on the mountain, more important than the plan are the people you have with you.

...If you go back in history, a few companies used difficult times to bolster their legions of talent. After World War II, all the government labs were shutting down, and engineers were streaming out. Hewlett-Packard was actually going through a layoff. But at the same time, Bill Hewlett and Dave Packard said the greatest opportunity they ever got wasn't technology; it was the opportunity to hire those engineers.

Fortune: But in a time of no credit and slowing demand, how does a company afford to bring people in?

Collins: [Hewlett-Packard's] answer was, How can we afford not to do it? You have to make the wherewithal. If you do not find a way to get those great people, you're not thinking long term enough. In the long-term research into tumultuous environments that Morten and I are doing, we find that great companies manage for the quarter-century...

Fortune: How do you distinguish the truly great talent from the rest?

Collins: The right people don't need to be managed. The moment you feel the need to tightly manage someone, you've made a hiring mistake.

The right people don't think they have a job: They have responsibilities. If I'm a climber, my job is not [just] to belay. My responsibility is that if we get in trouble, I don't let my partner down.

The right people do what they say they will do, which means being really careful about what they say they will do. It's key in difficult times. In difficult environments our results are our responsibility. People who take credit in good times and blame external forces in bad times do not deserve to lead. End of story.

The interview is a good, quick read.  Check it out.