Mindreef acquired by Progress Software

Wow - how did I miss this one??

Mindreef was acquired by Progress Software!

Quietly, Progress added another set of tools to their growing SOA portfolio. Through this acquisition, Progress picks up new SOA testing at quality management solutions. Congratulations to Frank Grossman the rest of the Mindreef team.

And again, I've updated the SOA Acquisition List:
http://www.momentumsi.com/SOA_Acquisitions.html

Iona acquired by Progress

Progress Software announced the acquisition of Iona.

This move continues to round out their SOA offerings by adding registry/repository, data services, message brokering and CORBA middleware. However, as others have pointed out, this leaves Progress with significant overlap in the ESB area. I'm confident that we'll be hearing from the Progress leadership on how they intend to resolve the redundancies that exist between Artix, FUSE, SOAPStation and SonicESB.

Naturally, here is the updated SOA Acquisition List.

Gartner: Force.com Case Study

Highlights from the Force.com Case Study presenation inlcude:

MS client/server developers will quit when you move to SaaS. Hire web developers to replace them. Those people then implement innovative ideas rapidly on the SaaS platform.

Don't underestimate the need for change management training in this or any software rollout.

Developers productive within two weeks.

Easy to train up people in India to be productive on the platform.

Myth is that data on SaaS platforms is not available. Customer downloads all data from all SaaS providers onto their SAn nightly.

Very excited about their release of SAML. Seems to be standard most vendors are coalescing around.

Gartner: SOA Design Patterns

As you know design patterns describe recurring solutions to common problems in software design. And recognizing and implementing these patterns is an essential part of successful Service Oriented Design. Below are 5 SOA design patterns that Gartner analysts have observed:

1. Multichannel Applications
2. Composite Applications
3. Business Process Orchestration
4. Service Oriented Enterprise
5. Federated SOA

Multichannel Application
SOA is a perfect fit for multichannel applications. This pattern separates the back-end business logic from the front-end logic and delivers full application functionality to a maximum number of users from various channels in a minimal amount of time while reusing the same exposed services.

Strategic Planning Assumption: By 2008, more than 66% of new midsize and large interactive applications will be designed to support multichannel access, up from less than 33% in 2007.

Composite Applications
Services used in composite applications may be new service implementations, fragments of old applications that were adapted and wrapped, or combinations of the above. Two types of integration technology are essential for effective operation of a composite SOA environment: 1) integration technology behind the service interfaces, helping users wrap and adopt various pre-SOA applications; and 2) integration technology helping users assemble and monitor transactions from services.

Strategic Planning Assumption: Through 2012, the majority of SOA-style applications will be interactive composite applications.

Business Process Orchestration
Business process management (BPM) suites are the tools devoted to implementing such SOA-based multistep processing flows. The BPEL standard is often used to document the designed metadata flow model. The metadata repository ("meta-database") is used to manage the proceedings of the business process model at runtime. Some steps of the process are implemented by calling
SOA services. Other steps require human intervention.

Strategic Planning Assumption: By 2009, more than 75% of SOA applications will implement some sequencing control outside of code of the service implementations, via external BPM technology.

Service Oriented Enterprise
The SOA-based enterprise model is a step beyond composite applications. Here, all applications are perceived as components of one integrated whole. No new application is created in isolation. Each application is built from reusable components that are available for use not only in their initially intended context, but also by other clients in other contexts. Essentially, the integrated composite enterprise consists not of applications, but rather business components — each an asset of the entire enterprise.

Strategic Planning Assumption: By 2010, more than 85% of enterprises will have combined their application integration and SOA management tools and organizations.

Federated SOA
The fundamental idea behind federated SOA is to logically split the enterprise into semi-independent SOA domains (for example, reflecting the enterprise organization in terms of subsidiaries, Business Units or departments), each with its own specific SOA infrastructure, governance processes and SOA Center of Excellence. Domains are then federated (that is, integrated — usually, but not necessarily, after the fact — to enable inter-domain sharing of services) through appropriate interoperability infrastructure, governance processes and organizational settings. "SOA federation" is the process of enabling a federated SOA by establishing the
proper technical, governance and organizational capabilities.

Strategic Planning Assumption: Few large organizations are able to establish a singular architectural blueprint for their entire IT. The best practice is to endorse domain independence and allow them to differ in technology and architecture in exchange for agreement to synchronize interoperability protocols and transports. Mergers and acquisitions are clearly candidates for Federated SOA.


Posted by Tony Cook

Gartner Update: The People Side

Massive changes coming:

IT organizations are becoming change saturated. Both home and work. In next 20 years will experience the world going through peak oil production of all time.

• Medicare/Medicaid big change. Baby boomers drawing down

• Social security

• Subdivisions/developments gated by water resources.

• Question. As a manager, how do I manage the people side of these kinds of changes.

Framework of change:
Why, what, who? Are we changing.

If we can’t get the people to achieve the change then we can’t be successful.

The gating factor on change is no longer technology (has it ever been? Chris) – it is people’s ability to handle/absorb change.

If our success in technology is gated by our ability to manage the people side of change then we had better figure it out. It was very disappointing to see in the target audience here at the Gartner conference how little effect current change management initiatives have had.

Key points are that as we knew, Executive sponsorship of change is vital. However executive sponsorship isn’t just “show up for the kickoff and sign the checks”. It really must embody active involvement. Even more worrying is that, again in the audience at the session, that most attendees don’t have a “structured approach”, nor proper communication plans.

It has been our experience that change management is viewed by the technical teams as “touchy feely, unnecessary, gets in the way.” Changing that perception is a change management in its own right. That being recognized, the whole “Awareness, Desire, Knowledge, Ability and reinforcement” cycle. The presenters thesis is that all change goes through this cycle. So if we attempt to encourage the technical teams just by giving them Knowledge, we are entering the cycle too early. We need to find ways to get Awareness and Desire enshrined.

Keynote...

Notes from Roy Schulte’s session on Event Processing.

The big key here is that Gartner are positioning EDA and Client Server (Request/Response) as subsets of SOA. We use many of the same concepts (standards based, abstracted, etc.) in both of the models. Event Driven Architecture is, however, better placed for situational awareness. Much of what Roy had to say was around the handling of Complex Events – typically described as aggregations of simpler events. He also made the key observation that an event stream can, of course, kick off a number of action streams. Using an airline example where as a result of some event data being received a whole raft of operational processes is triggered – from scheduling catering to preparing the ramp.

It is also clear from Roy’s remarks that even though we had the message oriented movements of the 90s, Event processing is still emerging. The usual innovators (financial institutions especially) have jumped onto this paradigm because of a combination of regulatory needs and some major competitive advantage in an environment when market analysis in milliseconds is now the norm.

BAM – Business Activity Monitoring leading to “real time BI” or genuine situational awareness is fast becoming a real possibility when event processing approaches are applied.

Gartner Coverage!

For all the MomentumSI coverage at the Gartner show, please visit our corporate blog:

http://www.momentumsi.com/blogs.php

Gartner Conference - SOA

MomentumSI will be sponsoring and participating at Gartner’s Application Architecture, Development & Integration Summit taking place this week in Orlando, Florida. This is a significant milestone for SOA as it represents the 10th anniversary of the AADI Summit…the underlying theme being “How to deliver value in a fast-changing SOA environment”.



Our Enterprise Architecture Solutions team will be on the ground at the summit and interacting with the architects, application managers and analyst in attendance. We will be posting daily blogs regarding the hot topics encountered and engaged discussions across SOA, application and Web infrastructure… stay tuned!

The Worst SOA Presentation I've Ever Seen

Jean Jacque Dubray is outraged. He declares:

"I watched Jim (Webber) and Martin's (Fowler) presentation tonight before I went with the kids see Kung Fu Panda. The two furious have given a presentation that's got to be by far the worst presentation on SOA I have ever seen, it is not even pathetic, it reached the level of Sadness. If you wanted to turn off customers you couldn't do it better. "

I watched it. It sucks - but I've seen worst. Jim and Martin keep talking about why we shouldn't buy an ESB. The early ESB's were largely just JMS products and proprietary. In addition, the vendors positioned the ESB as the center of the software universe rather than a valuable component that has a specific function. However, the concerns I voiced five years ago on this subject have largely been addressed. Regardless, I'll agree with Jim and Martin that the ESB has the potential to do harm if over used or used incorrectly (but this is true for just about everything).

Here's my beef with the presentation. Other than the lame attacks they did on the acronym SOA, they failed to present a solution to the problem they introduced: Attacking Silos of Systems. Jim and Martin avoid this issues completely. They basically say "use our stuff from 7 years ago and you'll be fine". This includes refactoring, continuous integration, test-driven development, dynamic languages, etc. Let's be clear, these are excellent concepts that all moderns software development groups should use (if they aren't already...) but it has virtually nothing to do with the problem at hand.

If you look closely at the pitch, they fail to discuss how to not create multiple silos in the enterprise, let alone how to remove the ones that exist today. Their approach is "program better" and "increment". Fowler is an icon of modern computing and the concepts that he championed in the late 90's were brilliant. However, this stuff is crap. The promotion of "use a dumb network" and "use agile techniques" are things SOA guys agreed on 8 years ago. It's a "no shit, Martin..." kind of thing.

Now, tell me how you're going to solve the silo problem. Attacking SOA with your Same Ole Agile crap is a non-starter. These guys will have to address the real problem and quit pushing their old books. Life sure would be easy if we could all just "do REST" and then call SOA a success.

McGovern on EA-Joke

In a recent post, James "fully insured" McGovern disputes my criticism of enterprise architecture. Mostly, he was disappointed that I went after Zachman, suggesting that EA's just don't care about that anymore (which I agree). I'll add that many of them feel that FEAF and TOGAF are also a bit too 'fluffy'.

But unlike me, James seems content with the state of his Visio and Powerpoint tooling, suggesting that he and his colleagues are doing just fine.

And on the subject of "silo funding", James states, "Funding models should never look like enterprise architecture and besides they are managed by two different entities..." I'm not sure what that means. My point is that the funding model should align with your business strategy. If the strategy is to provide a seamless experience for a customer as they cross through the silos, then the funding should reflect that priority. Without proper funding, EA's become security guards with a flashlight and no gun.




BUT - the thing that struck me the most about his post was that he never actually defended the enterprise architecture discipline. This could be that he feels that it doesn't need defending. Alternatively, he could have his own frustrations with the discipline. So James, which is it?

WOA wasn't important to me last week

I spent last week working with a couple of my enterprise customers. The time was focused around the Shared Service Center (formerly known as the SOA Center). Here are the big issues that we worked on:

- Improving the help desk for production implementation problems related to shared services

- Improving the ability to perform root-cause analysis for service exceptions

- Getting funding to pay for a better staging environment

- Changing the way we engage with large I.T. programs so that they don't get bombarded by 5 different CoE's

- Changing our 'service discovery' process to make it easier to project ROI for shared services

- Identifying a new set of processes that support organizations will have to follow if the business application requires high availability: "Gold, Silver, Bronze SLA"

- Modified and communicated changes to our "Service Architecture Document" in order to provide consistency in documentation detail

In my world, SOA refers to the organizational politics necessary for an I.T. group to perform their job efficiently.

SOA has evolved from 'web services' to 'an architectural style' to 'an enterprise architecture framework' to 'a specialized I.T. lifecycle and supporting organizational design' - to 'all of the above'.

If WOA wants to encompass the aforementioned activities - I want in. Until then, WOA is just a cool thing for analysts, press and marketers to talk about. Debating the HTTP verbs might seem like 'real architecture' to some but I am genuinely concerned that a 'shiny object of misdirection' is taking our eye off of the real problems.

WOA wasn't important to me last week and it won't be next week.

Is Your Programming Paradigm HOT or NOT?

Is your programming paradigm Hot or Not????

Well, you might not agree with my observations, but here's what I'm seeing:



Real Time
Let's start at the bottom of the stack: Real Time. Due to an increase in consumer devices, wireless networks, etc. we are seeing additional requirements for new low level programming. I wouldn't call it 'explosive demand', but the area does seem to be growing.

3GL
Surely, I'll get beat up here... but that's life. I am of the opinion that the amount of 'straight 3GL' coding continues to decrease. With the maturity of other paradigms people don't need to do as much old fashion hand coding as they used to. The bulk of this work has moved up a layer in the stack (3.5 GL / App Dev).

Application Development
These days more and more people write their applications on top of some stack (Java EE, open source frameworks, .Net, etc. Typically, they are using a combination of a 3GL with DSL extensions (JSP, ASP, etc.) In recent years, we saw the big application platforms (ERP, CRM, etc.) get (mostly) migrated to one of the aforementioned stacks.

Package App Customizations
The ERP, CRM and other packaged app vendors have increased their market share (as a percent of the enterprise footprint). This has moved traditional application development to more of a 'customization' model. Power users or application configurators use a workbench to add fields to a screen, modify reports, grant user access and other basic operations. New modules or complex changes are still typically done with more of an Application Development model except that the developer is expected to use the 'business framework' that comes with the system.

Platform as a Service
Although PaaS remains in it's infancy, it is growing at a rapid pace. From a language perspective, we seem to be seeing three options:
- The first option is to create a new language (like Apex) that is PaaS friendly (multi-tenant, sandbox, governed, etc.)
- The second option is to take a current programming language and throw exceptions with people call potentially harmful features (like Google did with their Python impl)
- The third option is to let the developer program in any language they want and let them deploy it on a VM. Here, developers are typically charged for CPU time and the VM is the sandbox, thus they don't really care what you do.


In general, we're seeing more and more development move up the stack. On occasion, we have to rework the stack, so we drop back down into lower layers and then work our way back up. Ultimately, the stacks get figured out and dollars (and work) flow into the layer of the stack that is most productive.

Why Enterprise Architecture is a Joke

Enterprise Architecture is a joke. And I don't say that lightly. My goal isn't to pick fights with enterprise architects - quite the contrary. I've got huge bets on EA - my time - my career - my money. My goal is to improve it.

Anyone who has been in our industry for any period of time has heard the jokes about EA... "EA's are the guys who program in PowerPoint." Despite valiant efforts to mature the discipline by groups like IASA, the OMB, The Open Group, The Zachman Institute as well as individuals like Ambler, the discipline remains fragmented and often unproductive.

In my opinion, there are several reasons why the discipline has not matured more quickly:

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.

Today's enterprise architects have been given the equivalent tooling as programmers in the 1960's. I feel like I'm bashing developers who were handed punch-cards, told to program in assembler and then scolded for their lack of productivity.

The good news is that most EA's are providing significant value despite their handicaps. The great news is that smart people have identified the problem and are actively working on the solution.

Key WOA Concepts

Nick Gall clarifies a few key concepts of web architecture around the URI:

---

On Thu, May 1, 2008 at 9:09 AM, Gregg Wonderly wrote:
> I think that there are two distinct uses of URIs. There are URIs that are never
> intended to be typed by people (or at least don't need to be), and there are
> URIs that only people will type.

I couldn't disagree more strongly. We should be doing everything in our power to eliminate the distinction between human understandable and machine understandable interfaces. Thus suggesting URIs for humans be different from URIs for machines is a step in the wrong direction.

There are three important reasons to make interfaces for humans and machines as similar as possible:

Debugging: you never know when a person needs to look under the covers to see what's going wrong. Why do you think the Internet and Web emphasize ASCII text-based protocols even though they are far less efficient than binary and will rarely be seen by most people

"Show source": human readable interfaces generally and human readable URLs specifically make it easier for developers (and even occasional scripters like me) to learn from one another

Serendipity: TBL and RTF emphasize that the web is designed/engineering for serendipity. Thus you never know (and shouldn't try to guess) which URIs people will or won't want to use directly.

Our goal should be to minimize the distance between UI and API. Assuming that people will see and use all URIs is a big step in that direction.
-- Nick

---

Spot on, Nick! I love the notion of 'minimizing the distance between UI and API'...

See: http://tech.groups.yahoo.com/group/service-orientated-architecture/message/10245

SOA Acquisitions List

I've updated the list of SOA Acquisitions:
http://www.momentumsi.com/SOA_Acquisitions.html


The new transactions were:
- Cape Clear to WorkDay
- LogicLibrary to SOA Software

I also added Sonoa Systems as a new target.

SOA Software Acquires LogicLibrary

Today, SOA Software announced the acquisition of LogicLibrary, a leading provider of software asset & reuse management. The terms of the acquisition were not disclosed.

SOA Software is best know for their integrated SOA Governance platform. The key word here being "integrated". SOA Software has both design time and run time platforms that share policy information seamlessly. For anyone who has felt the pain of integrating stand-alone registries and repositories with policy enforcement points, mediation points and web service management tools, you'll appreciate the beauty of having an integrated solution.

SOA Software is realizing a grand vision: unified governance and management of SOA across the Enterprise Lifecycle. The acquisition of LogicLibrary will give them significant depth in managing design and development assets. LogicLibrary has deep integration in IDE's and SCM's. In addition, it extends their reach into enterprise architecture by capturing reference architectures and development policies.

Through this acquisition, SOA Software is demonstrating the depth and breadth of their vision. At this point, it is unclear if the competition fails to see the vision or merely fails to execute on the vision. Regardless, SOA Software has raised the bar (again) before many of the competitors have caught up with the last bar-raising that they performed.

SOA and WOA Comparison

Several peopled (too many to name) have recently compared SOA and WOA. Unfortunately, virtually all of the comparisons are really more of an analysis of 'Web Services vs. REST/POX/RSS/AJAX'. For those of us who 'do SOA' for a living, this drives us crazy. We fought for years to get people to quit thinking about SOA and Web Services as being the same thing. Now we have both analysts and press undoing the progress that we had made. Ugh.

Ok guys - steal this:



Please consider extending this little framework as a way to do proper comparisons. If you feel the need to add rows, I encourage it. If you don't like the contents of a cell - change it, but for the love of God, please quit comparing Web Services and REST and calling it "SOA versus WOA".


As for the cute one liners: "WOA is the SOA that works"... "SOA is the internal cloud" :-) You guys kill me. This is excellent nonsensical dribble.

However, the idea of 'building your WOA on your SOA' caught my attention. My deciphering of this statement is "use the EA & Governance practices to ensure business alignment, proper sharing and quality while also using lightweight protocols to drive barrier-free consumption and composition." Assuming this is what was meant... I'd agree! Perhaps another post on this subject...

Targeted Markets for PaaS Providers

Yesterday I wrote that the Google PaaS offering was not suited for the Enterprise primarily due to the language of choice (Python). This had me scratching my head. The people at Google aren't stupid - they know where the money is... why would they make this decision. And then it occurred to me.

Google is betting that the Enterprise will spend more money on SaaS than they will on PaaS. As Gartner said,

“Ease of use, rapid deployment, limited upfront investment in capital and staffing, plus a reduction in software management responsibility all make SaaS a desirable alternative to many on-premises solutions, and they will continue to act as drivers of growth.”

Google has made a bet that they can lure start up companies and next generation developers to their platform by choosing a dynamic language that facilitates mash-ups. And by doing this they will be the preferred platform for many next generation SaaS companies. But which ones?

The Google platform doesn't really offer any 'enterprise grade' functions. What it does offer is simple access to the Google world of social networking, ads, etc. In its current form the platform is best suited as a platform to enable SaaS for large audience applications (like social networking).

PaaS providers are still trying to figure out their target markets. Companies like Coghead are chasing the SMB market, hoping to attract customers who want to avoid setting up their own hardware and paying expensive programmers. SalesForce is clearly going after the enterprise ISV's. We're quickly getting to the point where each of these players will have to announce their target market to the world. The 'one size fits all' model won't last.

Enterprise PaaS

The recent PaaS announcements from Google and Amazon have grabbed the attention of the enterprise customer. Utility computing, clouds, pre-integrated platforms and business services are all sexy topics. But these same companies also realize that there are huge hurdles to adopting these concepts. They're big ships - and they don't turn easily.

How do I get PaaS?
Companies will ask how they can take advantage of this incredibly disruptive computing phase. I'm in agreement with Michael Nygard who feels that "everyone will want one". See:
http://www.michaelnygard.com/blog/2008/02/a_cloud_for_everyone_1.html

Michael discusses the typical progression of high tech products:

1. Very expensive. Only a few exist in the world. They are heavily time-shared, and usually oversubscribed.
   
2. Within the reach of institutions and corporations, but not individuals. The organization wants to maximize utilization.
   
3. Corporations own many, as productivity enhancers, some wealthy or forward-looking individuals own one. Families time share theirs.
   
4. Virtually everyone has one. To lack one is to fall behind. No longer a competitive advantage, the lack of the technology puts one at a disadvantage.
   
5. Invisibility. Most people have or use several, but are not aware of it.

Michael goes on to say that he feels that Cloud Computing is currently at Stage 1 but it won't be long before large enterprises want their own. I'd argue that several enterprises already have their own cloud or utility computing environment. However, not many of them have a pre-integrated, platform sitting on the cloud ready for I.T. customers to use. There's a big difference between virtualized hardware and offering a software computing platform.

If you need to store data using the Amazon or Google offering, the options are clear. They have a couple services available - just grab the one you want and use it. To accomplish the same task in your average enterprise I.T. shop, you'd call up your enterprise architect, get a copy of the Technical Reference Model, identify the applicable elements, and then go to an infrastructure group to try and get them loaded so that you can test to see if they will work for their project. Ugh!

It will take a rebellion for enterprise I.T. to change but this act might be sooner than you think. Developers are already using Amazon and will quickly be messing with Google. They'll be telling management that they want to use this stuff because it is quick and easy to get going. (It's the same reason why people wanted off the mainframe and eventually ignited the client/server era).

In my opinion, Enterprise PaaS is inevitable. Organizations will not be able to switch to a purely outsourced model but will look for hybrid solutions, including creating their own PaaS. The PaaS model of the future will have to embrace multiple PaaS vendors (dare I say federated Paas). But, of course, the major infrastructure vendors will offer a PaaS-in-a-Box that mimics their own hosted model (think Oracle/BEA, IBM, SAP, Microsoft).

Who will win?
It's too early to say. Early indications are that it isn't Google. Their decision to go "Python-Only" is an extremely strong statement. Personally, I can't think of a single enterprise that considers Python part of their strategic computing platform (nor do they have armies of trained Python developers). The winner should be IBM, but they tend to think everything is a consulting problem. SAP isn't exactly known for their technology... Amazon has done some pretty cool stuff. Normally I would have discounted them, but who knows? Salesforce has an early lead but they don't have much of a footprint in the enterprise. Oracle/BEA and Microsoft both have interesting prospects in this space. If I were a betting man (which I am), I'd throw my chips on these guys.

Microsoft's 10 Year Old SOA Strategy

If you aren't familiar with Microsoft's SOA Strategy, I'll sum it up for you:

BizTalk + WCF + Vaporware = SOA

Yesterday, I attended a Microsoft SOA event to get briefed on their strategy. To say the least, I found myself disappointed. After 3 hours of showing slides and demo's I finally concluded that Microsoft's SOA efforts to date have been a failure.

At the heart of their strategy is BizTalk. It's the one SKU that they can actually sell that is related to SOA. And if you listen to Microsoft, you'll be told that virtually all SOA paths lead to BizTalk. If memory serves me, BizTalk was released in Beta in 1998 and became generally available in December of 2000. This isn't exactly a new SOA product.

Windows Communication Foundation (WCF) is a fairly new component that was introduced in the last couple years as a pluggable framework to enable the Web service protocols.

The third part of the equation is Oslo. This mythical beast is basically the next version of a bunch of products which will help build on the vision of Software Factories. Oslo will not be 'released' as a unit, but rather each individual product will get released on its own timeline.

Robert Wahbe, the Microsoft executive in charge of the Connected Systems vision, must either be sitting on some elaborate game plan which involves a well-kept secret to acquire some actual SOA products, or he's in serious trouble. It is clear that Microsoft no longer has the killer instinct that it had years ago. But even then, the lack of results in this area must stand out like a sore thumb.