Sunday, September 30, 2007

Cool Enterprise URIs & Mule

Patrick Logan expounds on my Enterprise Cool URIs post.

Ironically, Ross Mason commented on Patrick's post & Patrick responded with what we've been discussing lately at work. The ironic part is I spent the better part of yesterday messing with Restlet and Mule (Ross's product).

My point of view on this topic has changed significantly over the years like Patrick's. I have been pro-CORBA, pro-EAI, tolerant of WS-* (couple months where I built a couple of them in 2001), pro-message broker, pro-ESB, pro-JavaSpaces, and most recently pro-please don't hurt the web

I think that if you spend enough time with middle-ware, you eventually conclude that the best approach is to not hurt the web as much as you can and embrace a more-or-less-peer-to-peer model (i.e., how the web works). A year and a half ago, I preferred the message-centric to the service-centric approach. I have concluded that at the time I was misguided in how I thought I was dealing with the fallacies of distributed computing. I don't think there is anything wrong with messaging & there is a place for it for sure - I just think that the dominant integration protocol should be HTTP. I used to see messaging in the center, now I see it on the edges. HTTP should be in the center.

It is probably important to note that I am talking about coarse grained integration ... the integration of large domains (e.g., sales, manufacturing). I've heard this called the "federated ESB" approach although I wouldn't call it that. I've also heard it called the "ABC" model (application, business unit/domain, corporate). I'm focused right now on the communication at the corporate level - across domains rather than within them. I think that HTTP makes sense everywhere, but for lower level integration (A & B) there may be other choices (I still think that conceptually, you can't beat the Tuple Space concept for A - large applications).

Mule is an ESB, but that term is essentially meaningless today. MuleSource also refers to it as an "integration platform" and an "Enterprise Service Network". Mule allows and encourages any-2-any protocol "mediation". This is good. Mule can certainly be used in a way that does not hurt the web.

I have more learning on Mule to do. I was a little overwhelmed in working with it yesterday (lots of jar files, lots of XML config, examples that didn't help with what I wanted to do, docs that didn't answer my questions - typical newbie stuff). I did succeed in getting it configured to do what I wanted it to do after going down a number of rat holes & now have something to build on this week.

Mule may be a good runtime choice, but I agree with Patrick that an ESB isn't your architecture. Your architecture is things like reference data, meta data, the services & events you expose, your URI naming standard, security, and what is on the wire. You want to build these things so they can stand the test of time.

The appealing thing to me about hiding as much of this as possible behind a good URI naming scheme that doesn't change & HTTP is that I know for a fact that the URI & HTTP will be thriving in 10 years. I can't say that about any integration vendor let alone any integration vendor's current product set.

Taming the Traps of Traditional Thinking

Nice article: Mind of the Innovator: Taming the Traps of Traditional Thinking. It talks about the "seven sins of solutions" & how to tame them.

This is tragic & very true. We all see this:

IDEA loops. IDEA is an acronym for Investigate, Design, Execute, Adjust. it’s a codification of the human learning cycle...the one that starts disappearing around age 5, once we enter the formal school system. that’s when it becomes about the right answer and not the right question.

I have been fortunate in that I have been affected by this less than most. Some of it is personality type, most of it is probably due to really good parents who encouraged me to try things and not be afraid to fail.

We need to stop thinking about innovation as an outcome, and start thinking about innovation as a process. we need to move from innovations to innovation. Because as a practical matter, innovation, problem-solving and learning employ the same iterative process—blending supposition, logic, creativity and reflection

Experiments show that creative revelations come when the mind is engaged in an activity unrelated to the issue being addressed, and that pressure is not conducive to creative thought. recent research demonstrates that the ultimate break—sleep—actually changes our mind’s perspective.

There are pros and cons to being a light sleeper (me). I sleep 6 hours a night unless I'm exhausted. I personally need to be more disciplined in turning things off. Most of the time, software related "work" doesn't seem like work to me because I genuinely enjoy it.

There is this too: Enter the irrational fear of failure. Backing off is counterintuitive. it somehow feels wrong, like preemptive surrender. it’s scary to ease up, because we may lose our steam, or we may abandon hope. we get anxious when the answers aren’t so forthcoming, and we begin to doubt our creativity, abilities and intelligence, fearing that if we take our eye off the problem even for a moment, we may lose the energy we’ve invested.

I definitely have the fear of losing steam - I'm generally not afraid of failure though. I'm a "damn the torpedoes" type. This too has pros and cons.

Saturday, September 29, 2007

decisions: "follow the decisions you made" vs. "they were made"

I saw a link to this on Dan Creswell's

Train-Wreck Management by Mary Poppendieck.

The article is referenced on InfoQ. The Poppendiecks are my favorite methodologists. I have yet to be disappointed with Lean thinking.

I highlighted some sections that stood out to me:

Exhorting people to "be careful," "try harder," and "work smarter" is not useful if individuals have little effect on results. Rewarding or punishing people for outcomes that are not under their control can only result in discouragement - or in gaming the system. Instead, chronic problems must be fixed by finding their underlying causes and addressing these effectively. As Deming points out, this usually involves changing the system - the way things are done. And according to Deming, it is management's job to change the system.

Deming: All of the empowered, motivated, teamed-up, self-directed, incentivized, accountable, reengineered, and reinvented people you can muster cannot compensate for a dysfunctional system.... A well-run organization with well-functioning systems allows people from top to bottom do work of which they can be proud.

"There is something called standard work, but standards should be changed constantly. Instead, if you think of the standard as the best you can do, it's all over. The standard work is only a baseline for doing further kaizen. It is kai-aku [change for the worse] if things get worse than now, and it is kaizen [change for the better] if things get better than now. Standards are set arbitrarily by humans, so how can they not change?

"When creating Standard Work, it will be difficult to establish a standard if you are trying to achieve 'the best way.' This is a big mistake. Document exactly what you are doing now. If you make it better than it is now, it is kaizen. If not, and you establish the best possible way, the motivation for kaizen will be gone.

"We need to use the words 'you made' as in 'follow the decisions you made.' When we say 'they were made' people feel like it was forced upon them.

Standards are not about how work should be done, but how work is being done. You don't want the standard to be too perfect, because that leaves no incentive for workers to improve their standards.

That is, workers - led by their team leader - do many rapid experiments, find a better way, agree on the improvement, quickly document the new way, and use it. When a standard is improved, the decision for the change must be made by the people doing the work, so they won't feel it is being forced upon them.

When Deming said "change the system", he was talking about changing the complex, interrelated processes used to get work done. Deming believed that changing the system is management's primary job, and in order to do this, managers need competency in four areas: 1. Appreciation for the overall system in which work is done 2. An understanding of variation - and the true relationship between cause and effect 3. Constant pursuit of learning (improvement) through designed experiments 4. An understanding of the psychology of people When all of these areas are balanced and working together, great things can happen.

Ready. Fire. Aim

David Christiansen sent me a good article by Tom Peters on systems thinking and innovation. I couldn't agree more with it. It is astounding how much time is wasted with excessive planning.

Tom's post reminds me of the book The Myths of Innovation. I read it earlier this summer.

I'm a big believer in failing fast and learning. If you want to innovate, you plan a little bit, create a whole team, give them a wiki, foster a collaborative/transparent culture, set a short deadline, try something, measure it, and do it again until you are done.

I whole heartedly agree with this excerpt: I am an unabashed fan of MIT Media Lab guru Michael Schrage—particularly his book Serious Play. His principal axiom: "You can't be a serious innovator unless you are ready and able to play. 'Serious play' is not an oxymoron; it is the essence of innovation." And, in turn, the heart of his serious play is ... fast prototyping: "Effective prototyping may be the most valuable core competence an innovative organization can hope to have." His intriguing connection, which makes all the sense in the world to me, is that true innovation comes not from the idea per se, though it guides the work, but from the "reaction to the prototype." In fact, in a surprising number of cases (the majority?) the collective responses to a host of fast prototypes reshape the original idea beyond recognition—or lead one down an entirely new path.

A more succinct way to sum up how innovation works is Ready. Fire. Aim. Tom's article says he heard a Cadbury exec call his approach to product development. This phrase is often used as what not to do when it is exactly what you should do.

Update 01-OCT-2007 Tom has some follow up posts that are well worth reading: Systems Thinking II: My Summer Vacation and Systems Thinking III.

Here is a great quote:

"For C-sakes, quit drawing those f-ing maps and run some experiments, quick and dirty, and see if anything you are babbling on about actually works or makes the slightest bit of sense in the real world as we know it. And after you've done your real work, then you are welcome to write your 'complete theory of everything.'" (That was close to the actual script, minus many more f%^*s and about 25 minutes of elaboration.)

Friday, September 28, 2007

Enterprise Cool URIs

Cool URIs don't change.

We are working on some fairly large scale integration at work.

As you might expect, we are trying to not hurt the web.

As most older "enterprises", we have many many aging systems. But the "domains" or large groupings of our systems are well known & shouldn't change too much over the next 10-20 years.

I'd rather bet on the URI than any ESB vendor.

I started working on a naming scheme for our cool URIs today. I think that if we get that right, we'll be heroes.

With a URI naming scheme that doesn't change you get a very different, very simple view of your systems. Sure, there may be madness today behind those URIs, but over time that madness will hopefully start to go away. But your URIs will stay the same. A simple vaneer on madness that slowly becomes sane. Yay Cool URIs that don't change.

Pair Atom Restlet

I rewarded myself after a long week of teeing-up the next phase of a big project with some pair-programming with Patrick.

We did some messing around with Restlet & Atom.

It was a pleasant afternoon.

Restlet is a great little API.

Atom is a great little format.

Monday, September 24, 2007

Linux and open source software pay off for PayPal

Linux and open source software pay off for PayPal: When Scott Thompson left Visa to take the CTO role at PayPal in 2005, the Web company's data centre surprised him. "Wait a minute," he recalls saying, "they run a payment system on Linux?"

"I was pretty familiar with payment systems and global trading systems, but I just scratched my head when I came here," Thompson says. With his history of working on IBM mainframes and large Sun Solaris systems, the PayPal approach to computing seemed alien, especially for a company whose core mission was dealing with money.

PayPal runs thousands of Linux-based, single-rack-unit servers, which host the company's Web-presentation layer, middleware and user interface. Thompson says he quickly saw the economic, operational and development advantages of open source and Linux technology. He now sees no other way to do it.

"When you're buying lots of big iron, as I did in other places I've worked, your upgrade path is $2 million, $3 million at a clip. You just had to buy big chunks of stuff to scale," he says. "Here at PayPal, our upgrade path is 10 $1,000 no-name servers, slapped into the mid-tier of the platform. And we just keep scaling it that way. It's unbelievably cost-effective."

Via Matt Asay.

Sunday, September 23, 2007

GOSCON 2007 in Portland

I got a note from Deb Bryant regarding GOSCON. I went last year and it was great. I'm shocked at how much has happened in a year.

  • The week after I heard Larry Augustin speak at GOSCON, Compiere was forked. Less than a year later, a VP from Oracle took over Compiere hoping to turn it around.
  • JanRain was just getting started - I saw Jason McKerr speak at GOSCON. He had recently left OSL which was pretty high flying at the time. I remember him saying, "I'm speaking at an OSS conference, but our products aren't OSS. We did a lot with OSS at OSL." I don't remember much more about what he said. A year later, their CEO has moved on. I have no idea how they are doing besides that. But when that happened, it reminded me just how hard it is to start a company & how hard you have to work to make good software products that the market needs & will pay more $$ than it costs to make. Looking at the JanRain website, I don't know where the $$ will come from. I do think that OpenID is as good an idea as any though for identity. I get really tired of registering and remembering my password. I just don't know how they will monetize it given some of the stuff going on in that community. I hope they do though - clearly some talent there. And I have a natural bias towards all Portland tech companies.
  • Bradley Wheeler gave the closing keynote at GOSCON - it was incredible.
  • Stuart Cohen gave a speech as the CEO of OSDL (now The Linux Foundation). He now runs The Collaborative Software Initiave (CSI) - it is conceptually similar to Brad Wheeler's success with universities.
  • Open Source was a key focus of my daily work (along the lines of Brad Wheeler & CSI)- now it is just one fairly small aspect of it. Open Source has come a long way in a year yet has a ways to go. IMHO it is an unstoppable force. But lest we forget, it only makes up 2% of the software market. My personal opinions around open source have changed a ton in the last year. I remain convinced that it is the #1 disruptive force in the software market, but am a little more realistic about where it is and where it is leading.
Anyway, GOSCON is on again this year (year 3) GOSCON 2007, Oct 15-16 in Portland. Deb says: This year's keynotes include: Andrea DiMaio, Vice President and Distinguished Analyst, Gartner Research; Jim Zemlin, Executive Director, Linux Foundation; Skip McGaughey, Director of Eclipse Ecosystem, Eclipse Foundation.

Tuesday, September 18, 2007

Roy Fielding Video

Stefan Tilkov links to Roy Fielding presentation video. It is about 30 minutes long & well worth being late for work over ;)

I wish I could go to ApacheCon to see the latest in person.

Monday, September 17, 2007

Message Queue Panic

Now Dare Obasanjo is joining the spaz-out re: messaging, push vs. pull and such.

Also, Stefan Tilkov is momentarily a binary messaging bigot.

XMPP is IETF'd. It has been around for years (started in 1998 according to Wikipedia).

AMQP is a young upstart. Perhaps it will break out. I'm just saying it will be hard. It is really hard to get a protocol going. Time will tell I suppose.

At the end of the day, IBM MQ Series/WebSphere MQ still has over 90% of the messaging market last time I heard so in terms of application integration within the "enterprise", I'm putting my money on that continuing for the foreseeable future.

Perhaps overtime, AtomPub, XMPP, and HTTP can put a dent in that.

The whole pub/sub business may be an opening. MQ Series isn't known for that. They have a new 100% Java version that I presume does a better job. XEP 0060, AtomPub, etc. could be alternatives.

In the short term, I think that ActiveMQ has the best chance of taking on IBM MQ Series/WebSphere MQ in terms of the more classical messaging stuff. But then again, I guess that may be ok with IBM as they support Geronimo which includes ActiveMQ.

Seagull Architect

Speaking of David Christiansen, he recommended a good book recently that I have been reading: Manage It! Your Guide to Modern, Pragmatic Project Management.

He dropped "Seagull Architect" in some meeting we were in a few weeks ago. He got that from the book.

A few excerpts from Johanna Rothman (author):

I've worked on several projects where the architect was like a seagull. He swooped in, dumped a lot of poop in the form of PowerPoint pictures of the architecture, and left as soon as possible. He didn't stick around for the hard part of the project: making the product work in the architecture ore evolving the architecture so that the product could work by the time of release.

. . . But if your architect is overly fond of drawing programs and not fond of writing code and can't really answer the developers' questions about how to make the parts fit into a coherent structure, you don't have a real architect. Eliminate that person from your project . . .

Yep, PowerPoint doesn't compile.

I have been accidentally guilty of this before. My reason was being spread thin, not that I can't sling code. I hated doing that to the team at the time. And it was true, the team really suffered. Ultimately I removed myself from the project and they were successful.

The $100MM Canonical Model

A co-worker of mine in Indianapolis, IN David Christiansen has a good post with The $100,000,000 Canonical Model.

Lest we forget, there are no sliver bullets.

There are two extremes in my mind when it comes to data formats and integration architecture:

  1. Big Ball of Mud
  2. A canonical model / data exchange architecture will solve everything
The pragmatic approach, IMHO, is to start small and build these assets over time via projects. The wrong approach is to go off for months/years to create it. Clearly, an asset like this needs to be as simple as possible, embrace change, be accessible, and based on Atom. (ok the last bit was bias).

GData AtomPub Podcast

I just listened to The world of Google data APIs. It is 42 minutes long. I took notes.

Here is the agenda:

  • What "Google data API" actually means (the parts and pieces)
  • What Atom, Atom Publishing Protocol, and other tech behind GData are all about
  • What GData adds to the mix on top of Atom and APP
  • How Atom compares to RSS
  • What are ETags? And how can they help me?
  • Why REST, the style, was chosen for these APIs
  • Where REST makes sense, and where it doesn't. Resource driven vs. RPC.
  • What the first GData APIs were
  • How the killer app of syncing data with Google Calendar
  • How you actually use the APIs? What do they need to learn? What tools do we give them?
  • Can you write APIs that implement the same GData APIs?

Notes: Atom is an IETF standard in case you didn't know. RSS isn't.

Google has been working with Atom for over 2 years.

AtomPub provides a basic REST API - Google thought this was a great starting point. Atom leaves query to the student. Google uses URLs to do this. You can have output sorted etc. Atom doesn't say anything about this.

ETags were unfortunately not implemented. They chose a version number in the URL so that multiple people can write to the same entry. Plan to implement ETags in the future.

Are ETags magic? No, a lot simpler than they sound. A little string that tells you the version of the entry. Just a great way of making caching work & making the web more efficient.

Chose Atom because of momentum. And sold on REST. Not SOAP because the web is based on REST. Much easier for devs to learn REST than SOAP. SOAP require tooling. REST is simply manipulating tables of entries.

What are disadvantages of REST? AtomPub is just an implementation of the REST style. Difficult to map certain types of operations to REST - translation API example: send text & send back a list of options & then feedback how to improve the translations. Document centric request / response that was never saved on the server. Just a straight RPC call. REST is about manipulating resources.

How about transactions? Each request is essentially transactional. REST not concerned with multi-resource transactions.

How do devs use? Can use curl if they want to - some do create apps with shell scripts and curl. Have a Java, .NET, PHP, Python, Objective C API. Contributed APIs: Lisp (Patrick!), Ruby, Flash in development. It's just XML over HTTP - it's NOT THAT HARD!!

Authentication - "Client Login" is pretty straight forward auth. URL for uname/passwd where you get a token back that is your identity. Authentication for Web Apps - "Auth Sub" used for "on behalf of" type stuff. You can grant access to other web sites. You control who has access to.

Can I use Google Auth? They are meant to be open standards. Google legal hasn't signed off yet, but licensing will be worked out soon.

What is this "Kinds" business? Entries get passed around a lot - kinds concept is Atom categories to tag each entry with a "kind". Just gives more semantic information to computers (clients).

AtomPub Google Interop Event? 12 devs from different orgs came. Great success. Google's basic AtomPub worked fine. Google custom auth scheme was more problematic. After that everything worked smoothly. A lot of the impls built around AtomPub introspection document - Google doesn't use them much. Will in the future.

Any GData / AtomPub tips? Google has a particular approach to designing APIs. AtomPub good at certain APIs. Things that map well - RPC not one of them. On occassion Atom Entry is just a pointer to the real data (e.g., photos). Prefer to put data in entry as much as possible. There is a lot of art/style/parsimony to it. You can achieve a lot with 1 feed with a lot of query parms. Have to review APIs & ensure that they have good clean concepts: this feed clearly includes these types of elements.

WADL? Haven't found the need for it.

Atom can be tough to get at first, but once you do it is amazingly simple & then applicable to many. Very good programmers who don't understand AtomPub gargen/language can. Concepts are very simple. Feeds, entries, links to other entries. Very simple mental model once you get it. All APIs make the same. Very powerful.

Google working with the IETF on improving Atom/AtomPub. Introduced batch model that increases efficiency a lot. Auth. Teams in Google are very ambitious - hope to make publically available as drafts that can become standards.

Some talk of JAY-SAHN (JSON).

Saturday, September 15, 2007

Viking Bus

Erik Onnen (will answer to "Viking") has a good post on Apache HTTPD & using it as your integration bus.

Day by day I am making a cleaner break with my MOM bigot history.

There is clearly a place for messaging, but I think it's future is on the web. XMPP is of course perfectly positioned for this.

Friday, September 07, 2007


Matt Asay writes about a case against a SI (actually my first employer - it was called Andersen Consulting then):

[T]he U.S. Department of Justice is suing Accenture for allegedly receiving kickback-like payments from technology suppliers it recommended and/or implemented at DOJ. The alleged fraud was a collusion with big-name IT suppliers (e.g., HP, Sun) and smaller vendors (e.g., Vignette) to defraud the Government.

IT land is a very interesting place. It never ceases to amaze me. There is very interesting behavior in this market. There are all sorts of vendors all chasing the same Fortune 500 - 2000. There is tons of money, yet there is none. Everything is easy, yet everything is impossible. To survive/thrive in IT you need to develop many different types of skills. You must, however, maintain your integrity above all else.

Note: Obviously I have no idea if there is any merit to this case. All of the people I worked with and Andersen Consulting had heaps of integrity. I just felt the desire to beat the integrity drum today and saw this and leapt on it.

Viking Async Sighting

The Viking (aka Erik Onnen) spied AsyncWeb.

From AsyncWeb home page (bold emphasis mine):

The majority of today's popular java HTTP engines are built around the J2EE Servlet Specification - and are inherently synchronous in their operation. The typical order of play is that an individual HTTP connection is mapped to a thread of execution which reads data from the underlying socket, parses the request and forwards it up through the web container to the target Servlet - blocking until a response is completed.

As processing latency (as described above) increases, a real scalability problem is encountered: To increase throughput, it is necessary to increase the number of connection threads. This, however, is not the best way to scale - and depending on the JVM / operating system employed, having a very large number of threads can become a big problem very quickly.

A real problem then needed to be solved: How can we obtain a very high throughput - whilst dealing with high processing latency - without requiring a potentially unbounded number of threads? An initial area of investigation was to provide a NIO transport connector for an existing HTTP engine. However, existing popular HTTP engines built around the J2EE Servlet Specification have a blocking synchronous architecture throughout. Swapping in a NIO transport to such an engine does not solve the problem: We'd still need to scale processing threads in order to push requests up through the container.

What was needed was an http engine which provided non-blocking behaviour throughout - and so work began on writing such an engine.

Looks like AsyncWeb has been heading for Apache MINA for some time. Apache MINA is a network application framework which helps users develop high performance and high scalability network applications easily. It provides an abstract · event-driven · asynchronous API over various transports such as TCP/IP and UDP/IP via Java NIO.

Thursday, September 06, 2007

The things I drawr don't come true!?

Wait, those gigantic diagrams on my wall aren't going to compile with the next version of my bitchn' uber IDE? But the vendors said it was just around the corner!!

"Words and diagrams are all we have to work with. Mr. Klein. We need to live within their limitations. Seek not a single diagram to capture your enterprise architecture. Seek not a single sound bite. It is a hyper-dimensional thing you are grappling with. All you can do is capture fleeting glimpses of it with words and 2 dimensional views. Do not start with the wiring diagram. Mr. Klein. End with that as the least important view of your enterprise architecture. One view amongst many and a not-very-important view at that." Sean McGrath

Via Stefan Tilkov.

Wednesday, September 05, 2007

Tuesday, September 04, 2007

Both please

Dan Creswell picks up on the INATT business.

The problem is myopic views that focus on either only technology or only business. My point is that the lines are blurring. And the right approach is a balanced view.

If you spent millions and a year on a "build it and they will come" approach to deploying an ESB for your SOA platform, drink 3 shots of "It's Not Not About the Technology KOOL-AID" ASAP.

If you are ignoring the fundamental changes occurring in technology & the relationship society has with technology, drink 3 shots of "It's Not Not About the Technology ALONE KOOL-AID" ASAP.


I can't remember who's blog pointed me at this, but it is very interesting: CouchDB: Thinking beyond the RDBMS.

There clearly is a need for something like CounchDB. All the impedance of mapping document data to relational is quite tiresome.

I don't think that we'll ever get rid of relational databases all together, but at the very least it would be nice to have something for the cases where it makes no sense to map to a relational database and you want to effectively retain your documents. This could be great just to effectively store service interactions. Is it really just JSON or can I stick XML in there too? JSON is great and all, but there are an awful lot of XML documents out there.

I thought document storage like this was a great idea going back to 2000-2001. I was working at eXcelon (now Sonic Software) at the time. They had a product named XIS that was an XML database built on top of eXcelon Objectstore. It's issue in general at the time was scalability - I am not quite sure what happened to it after Sonic Software (Progress) bought eXcelon.

Monday, September 03, 2007

REST Conversation

Benjamin Carlyle has a good post on simplifying the introduction to REST here.

I love the question/answer style blog post. I have to do that sometime.

Sunday, September 02, 2007


INATT - It's Not Not About the Technology

INATT is pessimistic and self-defeating, even if it's not intended to be. It denies that there can be improvements, incremental or radical, in the ability of technologies to accomplish important goals. I disagree categorically with this. . . .

I think I may have even said this last week. In that case it really wasn't about the technology. But more often than not, It's not about the technology alone. as Andrew McAfee says.

IMHO technology is going to steam roll a lot of people and companies in the coming decade. Many are in denial. We are in an age where generations and generations of platforms have accumulated and we are drowning in technical debt. And we have generations of people that are accustomed to doing everything on computers, cell phones, and the Internet. These people will be the majority in 10 years.

Of course business execution aside from technology is crucial. The problem is that technology is becoming more and more crucial to business execution. INATT denies the freight train coming towards many businesses.

I predict that more and more companies will be coming to terms with the fact that it is about the technology like Amazon did. What happens when there is the Amazon of your industry?

Via Stefan Tilkov.