Blogger: Anne Thomas Manes

By invitation, I went to a special NDA analyst briefing last week on the Oracle 11g announcements. As I tweeted at the time, I found it very refreshing to hear a strong and definitive strategy underlying the announcements. It's a four-part strategy:

Complete: Oracle wants to be a one-stop shop. You can buy everything you need: applications, software infrastructure, tools, databases, management, and hardware infrastructure from Oracle.

Integrated: All components of the complete platform are designed (or perhaps refitted) to work with each other.

Best-of-breed: Each component in the integrated, complete platform is a credible, competitive product in its own right.

Hot-pluggable: The environment is standards-compliant, so, if you desire, you can replace a best-of-breed Oracle component with a comparable standards-compliant component from another vendor.

Unfortunately, it's a specious strategy.

Yes, the Oracle environment is complete, integrated, and composed of (for the most part) standards-based, best-of-breed offerings. But if you take advantage of the "hot-pluggability" feature, you break the "integrated" benefits of the environment, which derive from the common development and management systems (JDeveloper and Enterprise Manager). But Oracle has deliberately limited the scope of these products to work only with Oracle-supplied platform components.

As alluring as the one-stop shopping strategy is, organizations must learn to just say "no".  The reality is that no one has an entirely homogeneous environment. Oracle claims that Enterprise Manager supports end-to-end business process monitoring, but the concept breaks down if the process includes a .NET service or a third-party COTS application. A better solution is a management strategy that embraces diversity.

Diversity in IT systems is a fact of life. The trend toward heterogeneity is only going to increase as organizations take advantage of cloud computing or implement ebusiness collaboration systems.

As for the specifics of the announcements: Two things I really liked:

• Integration of TopLink and Coherence -- you can now use the Coherence distributed data caching system within TopLink
• Integration of Collaxa and Fuego runtime engines -- a single engine can now run both BPEL scripts and BPMN models

Blogger: Richard Watson

Measuring service reuse alone is not the right way to determine the value of a service.  SOA advocates tend to fixate on service reuse, and fill business cases with return on investment calculations based on reuse projections.

"Reusability is always overpromised."

This is a comment from the CIO of a Fortune 500 company interviewed by Burton Group. It reflects the risk in fixating on reuse. The memory of his application architects claiming that reuse is virtually guaranteed by object-oriented design has not quite dimmed. Likewise, applying service oriented principles promotes reuse, but does not guarantee it.  Reuse is a complex issue, as much cultural as technical.  As Jeremy Meyer eloquently says [i]:

Reuse is about people and education, not just architecture ... The truth is that even the most beautiful, elegant and re-usable architecture, framework or system will only be re-used by people who: a) know it is there, b) know how to use it, and c) are convinced that it is better than doing it themselves.

A service may never be reused, but still be used to create value in other ways: by being adaptable and less costly to maintain, reducing redundancy, increasing security and compliance through consistent enforcement of policies, to name just a few other desirable outcomes. Exclusive focus on reuse blinds us to these other outcomes.
I've had some great conversations recently with clients about calculating reuse. It's a tricky calculation.  Most reuse savings formulae look something like these:

Savings = Cost of Implementation - Cost of Integration
or
Savings = services * reuse * change
or
Savings = sum ( f (cost of integration at consumer, cost of change to service provider for new consumer) ) over #reuse, where f is "some function of".

Reuse savings are problematic because stated like this, as the client I spoke to says, "if I've saved all this money, where is it?"  Of course, it's deferred expenses, but that doesn't sound quite so valuable.  These formulae also overstate the value of reuse over time.  Some kind of decay function is needed to take account of a discount in the 'Cost of Implementation' value.  I'm out of college too long and not crazy enough to attempt the math for that decay function, I just know it exists. I'm not convinced it's always a decay function either.  If a service can take advantage of network effects then its reuse benefit over time actually rises.  And unlike radioactive decay, the value of the service can be refreshed occasionally, say when a changes to reporting regulations dictate a different set of rules and the changes required can be made in an isolated place instead of across the board.  But that gets us back to the value of service "use" not "reuse".

[i] Jeremy Meyer. In "97 things every software architect should know", ed. Richard Monson-Haefel.  Sebastopol: CA: O'Reilly. 2009.

Blogger: Kirk Knoernschild

A recent article on TechTarget claims that IT insourcing is on the rise. In other words, organizations are beginning to bring their recently outsourced IT functions back in-house. The article cites a few motivating forces for this change. Organizations have more control, can respond more quickly to business change, and are leery of outsourcing going forward due to unpleasant past experiences. The articles cites on of the reasons for outsourcing - it was cheaper - may not actually be true. While outsourcing may be cheaper short-term, the long-term cost may be more. Not an epiphany, for sure.

But what really caught my eye was the following quote from the article:

That's a rather profound statement. It took outsourcing for us to realize that collaboration with business users is a critical success factor on an IT initiative? Wow.

IT Labor

Since we're on the topic of outsourcing.... Another popular reason why organizations outsource is due to the IT labor shortage. Many claim there is a lack of qualified IT candidates. This reason is also the foundation of the H-1B program. Not so fast. I've never actually believed this was entirely true. My good friend Randy once said, "There's also a shortage of $2.00 per six pack micro-brews." If you're interested in IT labor, this Lou Dobb's video might interest you.

Conspiracy Theory

I take my car to a certified GM dealership, even though it's a bit more expensive than going to the hometown mechanic. Why? Because I know they won't use secondhand or refurbished parts. I also know they have the specialized equipment and expertise to work on my model vehicle. But if the GM dealership charged a 50% premium for the same level of service I could get at my local auto shop, I'd have no motivation to take my vehicle to the dealership. Now, apply this analogy to corporate IT.

If corporate IT charges a 50% premium over an outsourcing provider, but doesn't provide any strategic or competitive advantage to the organization, what's the motivation to use corporate IT? Instead, it's sound fiscal strategy to outsource. In other words, why should I pay $100 an hour for crap when I can get the same crap for $75?

For now, let's ignore the crap (that's a topic of discussion for another day), and instead focus on cost. $75 an hour may seem cheaper than $100 an hour, but only when you fail to factor in the number of hours it takes to complete a project. And the challenges inherent to distributed development, contract negotation with outsourcing providers, and more will impact delivery, which will increase time, which will drive up cost. So now, we're starting to realize that outsourcing isn't necessarily cheaper. Don't be surprised to see aggressive legislation on the table soon asking for an increase to the H-1B cap. Wouldn't it be ideal to have the best of both worlds? Cheap labor that's co-located! Really? Is it possible there's a causal relation between IT failure, motivation behind outsourcing, and the H-1B program?

Disclaimer: I'm not claiming that everything we deliver is crap. But there is no shortage of evidence illustrating some of the challenges we've had in delivering IT projects.

Disclaimer: I don't claim that we should abolish the H-1B program. However, there is evidence that H-1B visa holders are paid between $12,500 and $20,000 less than citizens. That's not the purpose of the program.

Blogger: Richard Watson

I hate putting newspapers and magazines into the green recycling bin before I've extracted every bit of written goodness from them. Unfortunately, I often have to, because my appetite for reading matter is bigger than my slice of reading time. Sometimes, though, I get to look back at a few weeks of the Economist, to make sure I've not missed something. This week my frugality was rewarded, as I came across a gem I'd missed first time around.

 This article [1] is about lessons we can learn from India's healthcare system. The first lesson we learn is from Vivek Jawali, a heart surgeon, and his team at Bangalore's Wockhardt hospital. They have pioneered "beating heart" or open heart surgery with the patient remaining awake for procedures including complex bypasses.

Because such "beating heart" surgery causes little pain and does not require general anaesthesia or blood thinners, patients are back on their feet much faster than usual. This approach, pioneered by Wockhardt, an Indian hospital chain, has proved so safe and successful that medical tourists come to Bangalore from all over the world.

Unlike the hidebound health systems of the rich world, he says, "in our country's patient-centric health system you must innovate." This does not mean adopting every fancy new piece of equipment.

This resonates clearly with the direction of my research this year. In the reincarnation of service oriented architecture, service modeling and other concrete architecture practices are the focus, not buying shiny new equipment. Service architecture innovation involves identifying services in a rich business context to prove their value. Adhering to the proven design principles of separation of concerns, loose-coupling and service-orientation to make sure they deliver value over the longer term by being flexible and maintainable.

Just as I found value in reviewing back issues of the Economist, my advice to our clients is to look back over their application platform infrastructure to squeeze the most from it. I spent much of the winter adding to Burton Group's Reference architecture for service infrastructure. I added decision making tools for service containers, service mediation systems and middleware. The overarching recommendation in each case is to use what you already have, as it probably fulfils 80% of your requirements. This means keeping the operating theatres running more efficiently, rather than building newer gilded halls. Concentrating on patient outcomes, not polishing the marble, or buying a new machine that goes "ping".

Over the years [Dr. Jawali] has rejected surgical robots and "keyhole surgery" kit because the costs did not justify the benefits. Instead, he has looked for tools and techniques that spare resources and improve outcomes.

...

Shivinder Singh, head of Fortis, a rival hospital chain based in New Delhi, says that most of the new, expensive imaging machines are only a little better than older models. Meanwhile, vast markets for poorer patients go unserved. "We got out of this arms race a few years ago," he says. Fortis now promises only that its scanners are "world class", not the newest.

This is the key lesson from the Indian healthcare providers. Patient-centric and outcome-oriented innovation plays to their strengths and allows more patients to be treated at lower cost. Building our IT around patient (business-) centric treatment  rather than technology is the only way enterprise IT can stay relevant, competitive, and innovative.

I like this article because it reminds us in this flat world[2] innovation is a global two-way street. Especially in the IT industry, we tend to view India through cultural cataracts as primarily an outsourcing location, rather than a centre for business and technology innovation we can learn from.

There's another twist in the Economist article. In claiming advances in Indian care have been enabled by adopting healthcare information technology (HIT) the author is on shakier ground. A glance at the blog entries from my colleague Joe Bugajski and the comments from healthcare professionals will confirm that those advances are coincident, not causal.

[1] "Lessons from a frugal innovator". The Economist. 16 Apr 2009.

[2] Thomas L. Friedman. The World Is Flat: A Brief History of the Twenty-first Century. New York, New York: Farrar, Straus and Giroux, 2005

Blogger: Kirk Knoernschild

Some remark that agile development processes have crossed they chasm - agile is mainstream and adoption is widespread. I'm not convinced that's true. Instead, I find that waterfall development is still alive and prospering. Unfortunately, the teams leveraging waterfall methods are not prospering. In fact, I'd argue that less than half of all software development teams leverage agile practices. I have no hard data that supports my claim, only anecdotal evidence suggesting it's valid. Regardless, it's disconcerting. Why?

Given today's economic woes, the impetus is on IT to show and prove their value. Continuing with status quo will not suffice. We're being asked to do more with less - fewer resources, shorter timeframes, reduced budgets, and more. While organizations look for ways to reduce costs, IT has been given a window of opportunity. It's critical that we take advantage of it.

So what can should we do? Look at what we can do to improve the quality of the software we deliver. Bake quality into the product from the beginning instead of attempting to validate quality at the end of the lifecycle. Look at what we can do to improve the efficiency of our team. Eliminate practices that aren't directly contributing to customer value. Look at what we can do to improve the transparency of the development effort. Engage the customer and share the good and the bad surrounding the current state of the system. These are just a few of the things we need to be doing now, and each have a direct correlation to reducing cost.

Agile processes and practices can help in these, and many other areas, but only if applied correctly and pragmatically. Adopting Scrum, XP, or any other agile method won't guarantee success. It won't guarantee agility. Agility is not defined by process adoption, but by the ability of the team to deliver valued software in a timely fashion. At this years Catalyst conference, I'll be leading a workshop titled Improving the Software Development Process. In this workshop, I'll be talking about ways to increase agility and improve the development process. Surprisingly, little of the discussion will focus on agile processes. Instead, the discussion focuses on techniques to improve software quality, maximize team efficiency, increase transparency, and more. I argue this is the essence of increased agility; not process adoption. We'll discuss actionable items that teams can use immediately.

If you're attending Catalyst, and are interested in improving your software development process, I encourage you to attend the workshop. If you do not plan to attend Catalyst, but are a Burton Group client, schedule a dialog now and we can discuss the issues, how they interrelate, and what you can be doing now to improve your software development efforts.

Blogger: Richard Watson

If you missed them this year, have a quick glance through the Jolt award winners.  The Jolt awards represent something of a zeitgeist in the application development world, so it's always interesting to see who has taken the gongs.

Real World Haskell winning the technical book prize reflects a real trend. I can contribute a data point here: the functional language sessions at QCon London a week ago were packed out. Anything involving Erlang, Scala, and Clojure was rammed and very buzzy amongst the delegates.

I tell people at every available point that my favourite computing text is still "The Structure and Interpretation of Computer Programs" by Abelson, Sussman and Sussman.  I believed when I read it first in 1990 and even more now that pure functional programming (i.e., no side effects) is one of the ways we can use application architecture to take advantage of multicore systems.

Steve Vinoski's new "functional web" column for Internet Computing gives an introduction to some of the reasons for the resurgence of functional programming.  So, we're all looking forward to Kirk Knoernschild's upcoming paper on language choice. Is the time right for functional languages to cross the chasm from niche into mainstream?

Blogger: Kirk Knoernschild

There seems to be a common myth that agile practices work well for small teams, but don't scale for large enterprise development efforts. Experience has shown me the opposite.  Certainly agile methods are a natural fit for smaller teams, who don't have the unique communication challenges and project management difficulties present with larger teams. In fact, it's these unique challenges that makes agile practices such a perfect fit for large teams. It's time to debunk the myth that agile practices don't scale.

I've written two pieces recently about using agile practices on big teams. The first talks about a macro process for making the practices work. The second clarifies a few items that may raise questions and cause for concern. I've also created a couple Burton Group resources that can help a team increase their agility. The first is a paper that talks about Rightsizing the Software Development Process, and the second explores Continuous Integration and it's many benefits. There is also other relevant and valuable information in our research library, including Agile Software Development: Not For Lightweights and SDLC Infrastructure: Supporting the Development Process.

This material underscores some fundamental elements that explain why agile practices are so important for any team. Strive to always have a functional system. Leverage the functional system to increase collaboration and garner important feedback from the customer. The more feedback you can get earlier in the development lifecycle, the better you'll know whether you're on track to deliver a system the customer values. As customer feedback and collaboration increase, so to does project transparency. Everyone - the development team and the customer team - understands the current state of the development effort. In fact, as the system evolves, you might even find that you no longer have a development team and a customer team. Instead, you've got "a team".

Blogger: Anne Thomas Manes

Eric Roch recently asked, "What Constitutes a SOA Failure?" The debate regarding SOA's demise still reigns, and quite a few people have posted numerous SOA success stories as evidence that SOA is still alive and thriving. For the most part, these success stories refer to individual integration projects implemented using an ESB or something similar. And while these individual projects may be successful, I still question whether the SOA initiative is successful. As Eric states in his post,

"I recently talked to a company that spend millions of dollars on SOA software and are now spending the next 18 months on their architecture frameworks and governance model. I have to wonder, given the time value of money, how that company will ever get to positive ROI. Especially since no one is actually talking about business related projects yet or even in the near future! All of this money was spent on toys for architects."

Joe McKendrick recently compiled some relatively positive information about SOA adoption trends, and Michael Poulin returned from QCon reporting a generally positive attitude toward SOA success. My response to Michael on the SOA discussion list was as follows:

How do they measure success/failure? Individual projects might be successful, but does that mean that the initiative as a whole is a success?

Most organizations that I've spoken with are using service-oriented middleware to do integration (SOI rather than SOA). Very few companies are actually rearchitecting their systems, i.e., simplifying their applications and data architectures in order to increase agility. Instead they are using WS-* or something similar to implement open interfaces to their existing applications (i.e., JABOWS). Over time, JABOWS typically results in increased architectural complexity and systems that are more fragile and more expensive than ever before. Although initially the initiative appears to be successful, the long term effect is actually a failure.

The best way to measure success is to measure it from the bottom line.

If an organization invests $15 million in infrastructure, education, new hires, consultants, project costs, etc, over the course of 5 years, how long will it take the organization to recoup that investment and start realizing benefits that can be quantitatively measured? Can they now actually deliver new solutions in less time and for less money than they could 5 years ago? Are their savings sufficient to offset the 5 year investment? If so, then I would agree that the initiative has been successful. If not, then you need to reassess the initiative and figure out why it has not delivered its promised benefits.

I have seen a small number of spectacular success stories. These companies have realized huge savings, they are able to deliver new solutions in significantly less time than before. All these companies adopted SOA as part of a much larger IT transformation effort, and they really focused on the architectural aspects of SOA.

I have also seen a number of companies that are starting to realize small cost savings and increased agility, but it's taken them 6+ years to get there, and they have not yet recouped their initial $15 million investment. It will probably take them another 3-4 years to break even. These companies will eventually be successful, but I suspect the business would think twice before making this type of long-term investment again.

And just in case you miss my point, I still strongly encourage organizations to invest in SOA. But my primary recommendation is to focus on architecture rather than technology. The goal of the program should focus on reducing the complexity and redundancy of the applications and data architecture.

Blogger: Anne Thomas Manes

A recent thread on the OASIS XML discussion brings to light an important but often misunderstood REST principle. The subject line of the discussion thread was, "RESTful XML for updates", and the following question was posed: "I would like to update a representation without having to PUT the entire resource representation back to the server." i.e., the representation of the resource is an XML document, and the user wants to update one element within the XML document, and wants to transfer just the changed element rather than the entire document.

Scott (the person asking the question) provided an example: the resource is a "widget", and it has various attributes, including "status" and "color". The representation of this resource is an XML document with a root element called "widget" which has child elements called "status" and "color". So how do you update "status" without uploading the entire XML document?

Quite a few people responded, and the prevailing recommendation was to create separate URIs/resources for every "thing" that you want to access or update independently. One person recommended reading Joe Gregorio's treastise on How To Do  RESTful Partial Updates. The discussion is informative, but I think Joe's suggestions impose too much burden on the user to understand the mechanics of his system. Which brings me back to the core topic of this post.

Look back at the original question, and you'll notice the source of the common misunderstanding: "I would like to update a representation without having to PUT the entire resource representation back to the server."

Scott should have said that he wants to update the resource, or more precisely, he wants to update the resource's state. The thing to remember is that a web resource is an abstract thing. It has a URI that names it, and through that URI and its uniform interface, a user can access and/or update its state. Users interact with the resource through representations of its state. But here's the kicker: The means by which you maintain the state of the resource should be invisible to users of the resource.

In this case, we're talking about a widget. As the provider of this widget resource, you need to maintain its state. But a user of the widget resource should not need to know whether the state is being maintained in an XML document, relational table, spreadsheet, or whatever. When the user performs a GET on the resource, you return a representation of the state of the resource--in this case, an XML document. But keep in mind that the XML document is not the actual resource. Even if you do use XML to maintain the server-side state, you shouldn't let the physical storage media constrain or restrict the means by which a user interacts with the resource.

If you want to enable users to update the status of the widget, then give them a URI that represent's the widget's status. When they update the status, your backend process must make the appropriate changes to the server-side state of the resource. From a developer's perspective, it's much easier to directly expose the physical state (e.g., the XML document). But as a resource provider, it's your responsibility to hide the limitations of your physical media from your users. 

Burton Group recently published two popular reports on IT metrics, measuring IT’s business value, and justifying IT's value.  The new reports target Data Management and the Software Development Life cycle perspectives. 

I found Kirk Knoernschild's coverage of 'metriculation' a refreshing and healthy departure from the customary 'metrics bashing' or 'metric as a panacea' perspective espoused by others. A few key quotes:

"Many IT organizations are leery of using metrics. In some cases, such caution may be warranted, especially when metrics have been used deconstructively. Metriculation refers to the improper use of metrics. More succinctly, metriculation is when metrics lie."

"Although software teams may already capture specific metrics, it’s imperative that IT evaluates how well those metrics align with business objectives. It must be careful to avoid “metriculation,” where metrics convey misinformation."

"Internal IT metrics are a valuable tool for helping the IT organization improve its internal processes, but they aren’t much help when it comes to justifying investments. For that, the IT group must define metrics that measure its business value (i.e., the value that IT contributes to the business)."

For more information on metriculation and measuring value, read Kirk's blog entry and research report.

Blogger: Anne Thomas Manes

I'm sorry that I missed Transparency Camp this weekend. Based on the TwitterVerse, it sounds like it has been a phenomenal experience.

Transparency Camp is a BarCamp style unconference taking place this weekend at The Institute for Politics Democracy & the Internet at George Washington University. The conference is described as follows in the unconference FAQs:

"This un-conference is about convening a trans-partisan tribe of open government advocates from all walks — government representatives, technologists, developers, NGOs, wonks and activists — to share knowledge on how to use new technologies to make our government transparent and meaningfully accessible to the public."

The geek-fest session I was most sorry to miss was presented by George Thomas, the chief architecture of the recovery.gov web site. Per the FAQs on the recovery.gov web site:

"Recovery.gov is a website that lets you, the taxpayer, figure out where the money from the American Recovery and Reinvestment Act is going. There are going to be a few different ways to search for information. Within days after the signing of the legislation, Federal agencies will start distributing funds, and you will be able to see which states, Congressional districts, and even Federal contractors are receiving them. As soon as we are able to, we'll display that information visually, through maps, charts, and graphics."

George Thomas was kind enough to post his slides describing the architecture of the recovery.org web site. The site is built using Drupal, and relies on REST, Atom, XForms, XHTML, RDFa, and SPARQL. Essentially, it aggregates feeds from all the agencies that are spending Recovery Act funds. According to the implementation guidelines associated with the Recovery Act, agencies receiving funds MUST make information available to recovery.gov via Atom or RSS feeds.

Blogger: Richard Watson

When enterprise customers negotiate license deals with software companies, source code escrow agreements are commonplace.  These agreements are three-party contracts between the vendor, the purchaser and a 3rd party escrow agent in which the agent stores the licensed source code, to be released if the vendor goes bust, or otherwise fails explicitly in its maintenance obligations (many shades of grey here!)  I've been at companies that have had to invoke escrow terms to recover and maintain source code from a failed vendor.  Of course, it's painful, but it's not disastrous.

We learned last week that Coghead, a platform-as-a-service (PaaS) vendor, has collapsed, citing difficult economic and fundraising conditions.  Coghead customers have no such escrow arrangements.  Far from it. 

Customers should download their data that is available through my.coghead.com before 3:00 p.m. Pacific time on April 30th.  However, Customers should not attempt to copy, modify, reproduce or reverse engineer any portion of the software that is part of, or used in the delivery of, the service.

(Extract from Coghead's "you're dumped" letter to its customers)

So all that development time, spent customizing UI layouts, workflows, business rules, and making integration work vanishes in a "cloud" of smoke.  It puts a whole new spin on Fred Brook's concept of "plan to throw one away".    Some Coghead customers will create better applications with the experience they've gained.  But learners were not Coghead's core market.  They were the DIY business person, the overstretched IT folk needing a solution for a quick situational application. 

This post by former Coghead partner, Michael Topolovich, is an extended but fascinating view on the promise and problems at Coghead, and required reading for anyone on either side of the PaaS business.   Apart from business execution problems that can sink any company, what's highlighted by Topolovich's post is the crucial requirement for a platform to have a thriving ecosystem of developers and 3rd parties.  Topolovich's company, Delivered Innovation, is now offering a Coghead to Force.com migration special offer.

SAP has picked over the entrails of Coghead, slurping up IP and staff, but:

SAP did not assume any of Coghead's customer relationships or obligations and, at this point in time, SAP does not have plans to continue offering the Coghead service commercially.
(Letter from the Coghead chairman, Paul McNamara.)

Why not support those customers?  There seemed to be magnetism between SAP and Coghead, for example SAP Ventures participated in the 2nd round of Coghead funding and the companies announced a partnership 9 months ago.  If I were both an SAP and a Coghead customer, I would be looking to SAP to provide some level of support, or at least a transition plan to a new platform.  SAP could grab this as an opportunity, and a cheap one I'm sure, to bootstrap a PaaS business with a ready-made customer base.

This post isn't intended to be schadenfruende laden; innovative companies go bust for many reasons, and I am an advocate of PaaS for the right situations (more on the right situations later).  My overriding recommendation is that if you are going to use PaaS, make sure you have an exit strategy.  Rob Styles has practical advice for mitigating the development risk, which I summarize here:
1. Keep the application URLs within your own domain.
2. Take regular exports of your data
3. Make sure you can export the application to run on-premise in some form. 

This ability, or lack thereof, to "download your application" is the crux of the risk around completely proprietary off-premises PaaS approaches like Coghead, unlike hybrid open/on-premise/off-premise approaches such a Google AppEngine and Microsoft Azure.

Blogger: Anne Thomas Manes

I recorded a podcast with Phil Windley last week, which he published on ITConversations. Not surprisingly, the topic was the death of SOA.

Also, we recorded the "wake" telebriefing, and it's available for streamed viewing on the Burton Group Channel on BrightTALK.