Why is it so hard to run IT like a business? Because, I can choose to be a customer of a business, and I can choose not to be a customer. Businesses don’t mind because there are usually lots of potential customers, so getting a market share of 1% can lead to a great deal of success.
IT does not have that luxury. If IT is to run like a business, then its services have to be consumed by some or all of the business units. It has to win MOST of the time that IT is in competition with an outside vendor. The more successful any particular IT service is, the less expensive it gets because much of the overhead is spread out over many customers. Economy of scale. This is how businesses work. Unfortunately, there is not an infinite supply of business units! IT does not have a broad array of customers to compete for. IT has a small handful of customers, and that is a problem.
If there are only three business units interested in a particular IT service, and two of them sign up, you have a 66% market share. That’s great… until one of them decides to outsource. Then you have dropped from a 66% share to a 33% share. If I was an automaker, or even a consulting firm, and I have a product line that goes from 66% to 33% market share in a year, I’d go through organizational chaos. Most businesses cannot scale back that quickly and neither can IT. In addition to the human cost, financial costs for the service’s remaining customer will soar.
You also have the fact that IT works for the same CEO as the customer (business unit) does. That means the CEO can issue an edict, and both the business units and IT must comply. If the business unit chooses not to comply, but IT does comply, then the business unit has little choice but to outsource.
You could be thinking “but how can a business unit ignore the CEO?” For many organizations, accountability to the CEO’s edicts are governed very differently within IT than they are within the lines of business. That is because IT is a cost center, while a line of business is a profit center. Profit centers are given a LOT more flexibility. Therefore, IT has a constraint that few successful businesses have: it has to comply with rules that its competitors do not have to follow.
Running IT like a business, with these economic and market constraints, is nonsense.
The more rational approach is to run IT as a two-headed organization. One is a governmental agency, able to levy and collect taxes and responsible for providing uniform services to all citizens (the business units). The other is a non-profit service provider that is under contract to the government, providing subsidized services to those citizens who need them.
The Governmental approach
Whether we want to admit it or not, this is often how IT runs. The cost of IT is simply deducted as a corporate expense. In other words, the cost of running IT is a tax. In large organizations, a simple formula may be applied to determine the amount of money each business unit needs to pony up. In Microsoft, your business unit pays a flat fee for each employee or contingent staff member that you have. For that money, you get a wide array of networking, collaboration, security, and information management services that you don’t even think about. The stuff is free and it runs.
The Subsidized Non-Profit Service Provider approach
While there are services that we all need, like a secure network and good collaboration and messaging tools (like Exchange and SharePoint), there are also services that some teams need while others really do not.
For small companies, or companies with very simple business structures, this is not even an interesting conversation except to say that the line-of-business funding pays for line-of-business software. It is still subsidized, because once the line of business application is running, the “government” side covers many of the operating, networking, and data management costs.
However, for a very complex organization like Microsoft, business-service funding can be a good bit more difficult. That is because any single service may have five, ten, fifteen different business units that could, potentially, be their customer.
This is where the “non-profit service provider” idea starts to take shape.
Here you can use some principles of business, like setting up a mechanism to insure that the business units who make the most use of a service are the ones that pay the most to use it.
For example, let’s say that your company is a retailer that operates branded stores (like Gap and Old Navy). Your company also sells uniforms to hospitals and health care institutions. Marketing to these two different markets is quite different. The marketing team for the branded stores will directly consume individual customer data at a far higher rate than the marketing team for the uniforms business. Therefore, they should pay more for the “Customer Marketing Profile” services.
It is a non-profit model because you are billing the customer, but you are not billing them for the full costs, and you cannot make a profit on it. The advantage of running IT this way is that the services provided are always competitive with market rates (due to the subsidy), while IT itself is buffered from the chaos that ensues when a business unit decides to use the cloud for a service and stop paying IT to do the work.
For years, we’ve heard the old saw: If only we could run IT like a business! But really, we cannot. IT does not have a market the way a business does, and IT cannot ignore the edicts of the CEO like an outside service provider can.
It is far better to make a clear distinction between the services that need to run as cross-organizational “platform” services and those that support one or more lines of business. The services that support one line of business can be funded by that line of business. The ones that support many lines of business can use a “non-profit” model like I outlined above. These are really two variations of the same model: the subsidized non-profit service provider.
One is government, the other is non-profit. Both live together under one IT umbrella.
Nilesh starts blogging, and his first post is of such high quality that I have to rave about it here. Nilesh Bhide, a trusted colleague of mine and a terrific architect, brings forth a tidbit of information too often overlooked: we can learn a great deal about the expectations, and therefore requirements, for our online services by referring to the knowledge, experience, and research that has been created for existing service businesses.
I’ve been on a roll lately, calling for the creating of a standardized approach to the partitioning of Line-of-Business apps.
One reader commented that we are a long way from “plug and play” integration.
The real answer is more subtle than that.
Not all business are alike. Therefore, one standard for all software doesn’t make sense. I’m not calling for one standard for all software. I’m calling for one standard for some software. Specifically, LOB supporting software. Allow me to explain.
First off: I’m talking about Line of Business software. So, if am excluding “storage in the cloud” or “hosted collaboration” services (like hosted e-mail). Not because they are not important… but because I’m looking at a different problem.
Line of Business applications are used to perform specific functions for the business. Particular steps in business processes are automated using LOB software. These processes are focused on things like “finances” and “human resources” and “order entry.” Useful things.
But what are these “things?” How do we describe the “things” that a business needs to define it’s operational world-view? These “things” are business capabilities.
A business capability is a description of the stable business functions (the things that must be done) in a way that allows the processes to change independently (processes describe how you do those things). So, you could say that when a customer calls your business with a request for information, the customer is going to invoke the “handle customer request” business capability. Whether that means a call center, or an IVR system, or just “folks in stores picking up the phone” depends on the business. The capability is stable. Every business needs to “handle customer requests.” How those requests are handled… that varies.
In Business Architecture, we talk a lot about business capabilities. The operational capabilities form a key part of the entire business model (just one part, of course).
For the sake of clarifying my call for standards, however, I’d like to break down the capabilities into three layers. From the bottom: Supporting, Industry, and Differentiators.
Now, I’d like to avoid a “taxonomy debate” right off the bat by saying this: I’m not suggesting that this is the only way to group business capabilities. There are lots of ways to navigate the list of business capabilities. I’m breaking them down this way because it is useful.
I have grouped the capabilities into these groups because these are the layers at which companies can collaborate. When you talk about standards, and creating shared best practices, and constraining software vendors, and leveraging the buying power of the market, then collaboration matters.
At the bottom of the stack, you have supporting capabilities. These are the things that every company needs, and every system contributes to, but is too-often overlooked. This is where you keep your information about customers, products, transactions, and obligations. This is the ‘base functionality’ on which the entire enterprise is built.
Companies can collaborate in this area because capabilities here provide no competitive edge. We mostly have the same needs here, quite often across a wide array of industries. Business schools teach courses in how to “do” the things that align with these capabilities.
The Industry specific areas are the focus of so many industry-specific standards bodies, from TMForum to Acord to hundreds of others. Even the HIPAA standard is a form of Industry-specific standard created to support an Industry-specific capability: the filing of medical claims. Everyone likes to collaborate here, but only other folks in your own industry really care.
The capabilities at the top are the ones that differentiate your business from your competitors. If your business is willing to collaborate in this space, then you are (a) rare, and (b) probably either location or geography specific or you are a protected monopoly! The rest of the organizations I come across, including Microsoft, have a set of capabilities that they keep quiet about because there is some value in how we compete.
Of course, the customer doesn’t see these things. For the most part, the customer sees the image that a business wants them to see: the things that make a business unique. That is what the brand is all about. In a certain sense, the most successful businesses wrap their “supporting” capabilities and industry-specific capabilities with a layer of uniqueness and differentiation. This is a slightly different perspective, but one that is useful.
Now, we have divided up the S+S space to focus on Line of business services, and within that, we have divided up the capabilities of a business into different layers.
The area where I believe we should standardize is not all software, or even all line of business software, but only the software underlying the Supporting Business Capabilities.
In this space, and ONLY in this space, do I see the need to create the first row of standards.
Then, on top of this space, I can see the need to describe Industry-specific models, like NGOSS/TAM for the telecommunications industry.
The reason for doing this goes back to my initial post about a Shared Global Integration Model.
One thing that is useful to realize about this standardization: I’m including the data model using the same hierarchy of business capabilities. In other words, we should collaborate on the ‘supporting’ business model and allow industry-specific groups collaborate on the information that surrounds the center. This creates an information model with many layers, each managed by different people.
I am getting somewhere with all of this, by the way. My next post will go further into why the standards bodies are not getting this right today. After that, I’ll talk about the software that we should develop to support / enforce / encourage these standards.
Sometimes, in a long struggle, a goal that was strategic one day, becomes unimportant later. This happens when some underlying assumption is challenged, when some previously secure resource becomes unavailable, or when the behavior of large groups of people shifts.
|(Caveat: my views are my own, and may or may not be shared by my employer, Microsoft. Investors, customers, partners: please, do not make financial or purchasing decisions on the basis of my opinions. Nothing I say is “official.” God forbid.)|
That doesn’t mean that the battle was lost… just that its strategic value is lost. Winning that battle was hard-fought, and valuable at the time, but that battle, whether won or lost, just isn’t as important any more.
For years, Microsoft has fought to put the most software onto the desktop of every personal computer in the world. It is no secret that “windows on every desktop” was a rallying cry for this company for a while. Although we are not so focused on a single product anymore, we still want to get our products on as many machines as we can, and machines into as many homes as possible. That drives adoption, which creates a de-facto standard, and creating a compelling “virtuous cycle.”
We’ve been criticized for this strategy. We’ve been lauded for this strategy. We’ve been sued over this strategy. We’ve been successful because of this strategy. Microsoft software on every desktop!
But now I’m going to venture an opinion… a prediction of the future.
In the future, winning the desktop won’t matter as much anymore. That goal, in the coming decade, will gradually decline in importance. Putting a bunch of software on every desktop will be nice, and it will earn a lot of money, but, IMHO, it won’t fund the next level of growth for Microsoft.
A new battle has emerged, one for the hearts and minds of the future generation: the generation of the digital native. This is a battle of love and passion and inventiveness, a battle to earn the good will and the respect of a billion people. A battle we cannot lose.
Our past is based on the desktop. Our future is based on the net-top.
What is the net-top? The net-top is the Internet equivalent of the desktop, a grand shared space where all applications are installed already, and you pay for only what you use. Where ultimate choice drives the day, where small players and large players alike have an much more even playing-field. Where it doesn’t matter if you live in China or India or Brazil or the USA… you get the same applications, available in the language you choose, and you can choose which ones to use because they are all already installed through the web and Silverlight and services.
The net-top is the new surface of computing. It is the Internet, plus service, plus software that is needed on the device to make up for the inherent frailty and constraints of the network. It is neither open source nor proprietary. It is not a browser. It could be a mashup surface that provides access to every internet software+service application, already installed (even big-bad Microsoft’s services), along with access to the virtual storage needed to hold the information.
(Note: Hosted desktop services are part of the net-top, but not all. I’d start there, but my definition far exceeds the hosted desktop solutions that are currently available).
I believe that, eventually, the service is all that will matter, and the download of software to the desktop will be both free, and very simple to do. It won’t matter where the desktop lives: on a laptop or a hosted desktop or a PDA or a telephone or in a car or woven into the material of your winter coat. What will matter is the service. Data will be “in the cloud,” and available to every service that needs it.
The control of the CIO over the contents of the corporate desktop will wane. This trend has been going on for some time, and CIO magazine has not only recognized it, but recommended that CIOs embrace it. (See Users who know too much). It is time to let the users have the control. The force is unstoppable anyway. Initiatives and products that attempt to wrestle control back to the CIO will meet with success briefly, but will ultimately fail to gain foothold as the tidal wave of user-self-determination washes away these obstacles.
Information will move to the ‘cloud.’ There is no avoiding it. The individual users who create distill information from data will control that information, often outside the boundaries of the corporate walls. Secrets will become harder to keep, and IP will become even more difficult to control, even as IP becomes more valuable to the survival of the top corporations of the world.
Corporations will install their on local or proxied versions of popular Internet services in hopes of keeping intellectual property assets from leaking out. In-hosted services, however, will fail to prevent the migration to the internet cloud, as partnerships and communities will increasingly extend well past the boundaries of the corporation. As they do, the ‘center of gravity’ will shift away from the corporation to the community: an extended space defined by the people themselves, with their own rules for information management.
To cope, Corporations will purchase “spaces” in popular sites for members of their company to collaborate safely. IT departments will begin to adopt common standards for protecting that data, and will push those standards on large service providers. A new conversation will emerge, from the IT community that, in the past, drove very few standards. So while corporate information will move out of IT, control over how it is managed will collectively shift. Information will be assured and managed, not controlled.
All of this is driven by the net-top. This is the new space, and Microsoft is coming. We are creating products an increasing rate, moving resources, shifting priorities, reorganizing
. The movement is taking hold inside Microsoft, and that is an amazing thing to watch. I was here when Microsoft “discovered” the Internet, and this time, there is even more seriousness than in the 90’s. Microsoft will not, cannot, has not, ignored the net-top.
Sure, folks like Salesforce and Amazon are already there, and winning customers with excellent products. But we are there as well, and we are driving forward at an accelerating rate. Competition is what drives us all. No one loves to compete more than Microsoft.
And you can’t count us out. Not on something we are serious about. A long time ago, Microsoft was not first in spreadsheets, but now Excel is the king of spreadsheets. Once upon a time, Microsoft was not the first in presentation software, but now elementary school kids learn Powerpoint as an essential job skill. I don’t know the market share of Exchange or SQL Server, but I’m certain that we have gained, gradually, relentlessly, continuously.
We are serious about the net-top.
The battle has been joined.
There’s been talk, for years now, about concepts like Enterprise 2.0 and Web 2.0. We are all so enamored with technology, we sometimes forget that it is about the customer. There is a Customer 2.0 in here, and I’d like to speak to her.
Have you met Kai? Kai is the name that we (the MS IT EA Team) are thinking of giving to Customer 2.0. She is young and lively and one of the most demanding customers we’ve had to deal with on the web. Know why? Because she expects us all to grow up.
Geeks and Nerds: Kai is calling to you. She is calling to you to make her internet experience Fun, Social, and Engaging. If she uses your services today, that does not mean she will use them tomorrow. She is brand loyal, but your site will hold her attention primarily if it holds the attention of her community. Her group. Her peeps. Welcome to the fad.
No more expecting Kai to live with badly designed sites. She learned about programming in high school (or middle school) and is unafraid of making her own mashups. That said, she doesn’t need to. You will provide something beautiful to her. She is outright offended when she sees a site or service that she feels is not professional or trustworthy. She’d never hand her friends over to something klunky.
A few demographics will bring this into focus. Kai may live in a western country… or not. She is as likely to be speaking Mandarin Chinese or Hindi as she is to be speaking Spanish or English. Gabriel Morgan put up a good post on the facts surrounding this interesting new person. (link fixed –nm)
In Enterprise Architecture, we are innovators. We talk about, and hopefully practice, the fine are of alignment. We want the business and IT investments to align. But we cannot possible do that unless the IT team is drawn towards the same destination as the business is. We have to understand the aspirations of the business, and then understand the needs of the customer. Only then can we look at where her needs coincide with the services we offer. Only then can we justify the investments we are making. That is alignment.
In order to go after a customer like Kai, we need to be a different company, and we need our IT department to change. This is the crux of Enterprise Architecture. It is not just about aligning to the business… it is about aligning with the business to the same end goal: the customer.
The first step towards building a new Enterprise Architecture is understanding how different we need to be in order to meet Kai’s needs. So we wrote down Kai’s needs. (Marketing to validate). From that, we looked at how the business will need to react to meet Kai’s needs. Then we looked at how that will create or exacerbate the forces on IT.
Honestly, unless we change, we will snap into pieces. IT cannot possible hope to deliver to a rapidly innovating business model without changing the way we do business. And that is where EA comes in. If we are to change… how do we do it? Change without a goal is chaos. It is up to EA to envision not only the application infrastructure, but also the organizational roles and responsibilities within IT, that will make IT successful as we work, as a company, to win over Kai.
This new customer, and our desire to chase her, is the compelling event that drives SOA, and that pushes us towards a coordination model. That understanding lives in EA. And honestly, no where else.
No organization is perfect. We each can look around and say “stuff is broken here.”
So, how to fix things?
First off, why fix things? After all, if I am a lowly programmer, it is not up to me to fix things, right? After all, they pay executives, don’t they? Shouldn’t an executive earn their salary by fixing the stuff that’s broken?
First off, the executives whe are responsible may not fix things. Lots of reasons:
- They may not see the problem you see.
- They may consider the problem you are seeing as “benign” and therefore not worth fixing.
- They may see the problem but they may see no reasonable way to fix it within the budget/people/culture of the organization.
- They may see the problem but they may have decided not to fix it because other problems are more strategic.
- They may have chosen to create the problem as a tradeoff when fixing a different problem.
Know what? Most executives see the problems. They see them way too much. When I was a manager, there was a standing rule in my office: Bring Solutions. It’s a pretty common rule.
So if you want to fix the broken stuff, you have to do a few key things.
First and foremost, you have to show that fixing this problem is aligned with corporate strategy. If the company wants to have four completely independent divisions, you will get nowhere by convincing an executive to merge all the purchasing decisions.
On the other hand, if the company wants to take on a new market, and they have not done so, show that your change will help them to do it. If you change doesn’t align to strategy, drop it. Be the “doubter” and prove it, without a shadow of a doubt, that fixing this problem is the right thing to do and this is the right time to do it.
Once you have this, find the person you have to convince. That’s difficult. Spend some time thinking about it. Is it Joe in Marketing, or Sue in Sales, or Tom in operations? Think: If I were “Joe” and I decided to fix this problem, what would I do? Am I the right guy to fix it? If you have this person targeted, think about what it will take to change their mind. Do they respond to numbers or emotions? Do they believe in instincts or principles? Do they think short term or long term? Tailor your message.
So, what’s in the message?
- Demonstrate that the problem exists by demonstrating the financial implications of the problem. Everything has financial implications. Everything. Get your facts in line. Get the folks who are supplying your facts to agree with your conclusions.
- Demonstrate that the problem is worth fixing. Find a positive spin: we will perform better, save money, compete better. Demonstrate that the problem you are trying to fix shows up a lot in ‘unprofitable companies’ (no one wants to be in that category).
- Share success stories about companies that have fixed the problem: what they got from it, how much better life is for them, how there are so few negative impacts and so many positive ones. Remove barriers to adoption.
- Demonstrate how their decision to fix the problem will align with corporate strategy. Show how it will make the company go “faster” where they already want to go. This is very important. Paint the future and show how terribly important that they fix the problem you see before they can get to the future.
- Demonstrate that you have thought about the tradeoffs that may have created the problem and show how your solution doesn’t violate those tradeoffs. Tell the story of a company that maintains its focus, your company, in the face of changing business climates, by leveraging the thing you want to fix.
- Ask for the sale: Have a plan that they can sign up to. Make it inexpensive: even if it is a plan to build a plan. Get your executive to agree that it is worth a shot to dig a little, see if the solution can be implemented. Look for test cases or pilot projects that you can apply your fix to.
You can fix things. If you don’t, no one will.
Have you ever woke up in the morning with an idea in your head that you simply have to write down? I just did. Here’s the idea: Everyone talks about how important the catalog (or repository) is to Service Oriented Architecture. It isn’t.
The reason everyone wants a catalog is simple: If I create a uniquely valuable service, and I want people to use it, I need a place to advertise it. So I put it in a catalog. The catalog contains useful information like what the service is, and what it does, and who made it, and how to call it. Useful stuff. Sears Roebuck, circa 1893.
So how can that be unimportant?
Because this is a case of ‘doing a really good job of solving the wrong problem.’
A friend of mine and fellow architect here in Microsoft IT named Mohamed El-Ghazali changed the way I think about service contracts. And Gartner changed the way I thought about “what makes adoption work” and together, there’s a powerful brew. It took me a while, because these ideas are “just different enough” to make me pause, but between these two sources, they had the intended effect, and now I can say, without blinking, that the catalog is not the high order bit.
Why? Because the catalog is not an IFaP. It is a list of chaos.
If you have 20 services, or even 50 services, a catalog is really useful. I’m looking at an architecture that will require something around 500 enterprise information, activity, and process services, about 200 infrastructure services, and countless ‘point solution’ services. There is no way a list will do. No human can remember it, or use it. Duplication and overlap will prevail. Face it, the catalog doesn’t scale.
So where does the solution lie?
How about looking to the past to find the future.
I call your attention to the history of the Periodic Table of Elements.
If you are not familiar with the history of the creation of this simple yet extraordinarily powerful concept, you should read this page. Two key concepts I’d like to pull out:
First off, by creating the periodic table of elements, Mendeleev created a situation not only where elements could be classified, but where missing elements could be predicted.
Between 1868 and 1870, in the process of writing his book, The Principles of Chemistry, Mendeleev created a table or chart that listed the known elements according to increasing order of atomic weights. When he organized the table into horizontal rows, a pattern became apparent–but only if he left blanks in the table. If he did so, elements with similar chemical properties appeared at regular intervals–periodically–in vertical columns on the table.
Mendeleev was bold enough to suggest that new elements not yet discovered would be found to fill the blank places. He even went so far as to predict the properties of the missing elements. Although many scientists greeted Mendeleev’s first table with skepticism, its predictive value soon became clear.
This meant that not only did Mendeleev help to understand the list of ‘needed domain knowledge’, he actually created boundaries that empowered other people to focus their efforts and deliver incredibly quick innovation. This innovation came from people he had never met.
The second thing I’d like to highlight is that the original table was useful but it was changed as knowledge increased to match a more modern understanding of chemistry and modern techniques for measuring atoms that was not available when it was developed. In other words, the concept is good, even if the implementation is iterative. (19th century agility). The boundaries remained, and the table stands today as a fundamental artifact in the understanding of our natural world.
What does that have to do with SOA?
I am creating a similar table of services based (loosely) on the layers defined by Shy Cohen, message exchange patterns defined by the W3C, the work on Solution Domains that my team in IT Enterprise Architecture has started, and the business behaviors that I see as necessary to accomplish a partitioned design. The goal is to create an all-up IFaP of services based on multiple spanning layers.
Unlike the periodic table, this will not be bounded by physics. Instead, it will be bounded by the data elements and solution elements defined by performing a Solution Domain mapping exercise against the enterprise. Your organization will have different elements, but either way, there will be boundaries, and that will, I believe, foster organized and directed effort, creativity, and discoverability.
I believe the value will be clear.
- We will know what services we need to develop to meet the needs of the enterprise. We can even prioritize the list and create a roadmap showing the CIO when we will be “done.”
- We will have basic patterns already established for how they will be called and what they will return. This reduces a huge amount of churn and will give brave developers the ability to resist the “not invented here” plague. The patterns can be designed to include all the needs of the test and support teams that are normally ‘left out’ of application specs but are ever more critical to the success of SOA.
- We will have generic test harnesses in place to test them before they are written, allowing test architects to build reusable test value, while at the same time relieving project teams from writing difficult and complex test software to support SOA.
- We will have sufficient information to estimate their cost by the team that must build and maintain them, providing some visibility to the cost of developing an integrated application. This gives us the ability to seperate out the incremental cost of SOA from the cost of application development in general.
I’m pretty excited about doing this, and I think it is a strategy that can work.
So what part of this kills the catalog?
The catalog helps a programmer to find the name of a service that performs a specific purpose.
However, if I know the purpose, and the list of activities is a constrained list (as is the list of data subject areas), then I can create the name of the service and just hit the infrastructure up for it. If it exists, the service will respond with details. If not, the infrastructure can respond with information on what is needed and where it should live.
It really is that simple.
We go from this:
The catalog describes the service infrastructure (bad)
The catalog is the service infrastructure. (good)
And in this world, the catalog is informative, but not required.
Harry Pierson asks a great question in his post on REST (A REST Question). I’ll summarize his excellent post this way: what makes something RESTful? Is it the protocol or is it the constraints in the architectural style?
Rest is succeeding where SOAP has had a hard time. Clearly, the REST folks are doing something right. We want to bring some of that “right thinking” in to SOA initiatives.
The thing is this: there is an interrelationship between the REST architectural style and the REST protocol and mechanisms. In a sense, each has had some influence on the other. But I’m going to take a stand and pick the ‘most important one:’
I believe that the REST IFaP is the high order bit.
In case you may not be a regular reader of my blog, an IFaP is a grouping of attributes (Identifier, Format, Protocol) that, when viewed as a unit, forms the basis for Middle Out Architecture. Each of the successful Internet standards, from HTTP to SMTP, has an IFaP at the heart of it. IFaP is the generalization that allows for adoption, and in this business, adoption is the key indicator of success.
The question that Harry asked was this: if we use the REST style but we drop HTTP, is it RESTful?
The HTTP request and response mechanism is part of the core IFaP for REST. Therefore, if we want to maintain the adoption, and therefore, the success of REST, we cannot do it without using URI and HTTP. It is not clear to me if the REST world is more aligned with JSON or XML for format, but it is clear that these are the top two standards.
My opinion, of course, is mine alone.
Michael Platt posted a set of observations recently that offered up some troubling conclusions. In his post, which you should read, he noted that most of the folks interested in creating Web 2.0 sites were not talking to their IT departments to make them happen. These creative and interested business and marketing leaders were turning to external firms to create their Web 2.0 sites, while the IT departments at the very same companies were reporting that their business customers were not interested in Web 2.0!
I live in an IT department. I can certainly vouch for the IT side of that story. I’ve gone to various business teams and asked them about Web 2.0 capabilities, and they appear interested, but not enough to fund a project that will allow their content to ebb and flow, or empower their segment of the community to interact.
Personally, I find it both frustrating and a little humiliating, but I don’t think it is an IT problem per se. I think it is the bruising politics of IT – business relations. In other words, there is so little trust, that over time a kind of “mean politic” has emerged which is fought out mostly in the budgetary space. No one gets a dime without BOTH teams spending a fortune on “oversight” to prove that the projects won’t fail or will deliver (know what? Oversight doesn’t deliver projects that meet business needs. Agile does. Hard lesson. Different post).
In the climate of massive oversight, and detailed inspection, there are rituals that MUST be followed in order to make something creative or interesting happen. Those rituals are governed by people who are, to be honest, tired of following them. For some reason, we all accept the basic assumptions that these rituals are actually useful or necessary.
In this climate, if a business user really wants to connect with their community, they have no way to get their project funded. It takes huge amounts of time and effort on the business side to create a justification for a project, so that the project costing can be fed to the financial teams who perform the budgeting for IT, where senior folks inspect every detail of the business case and rank projects on the basis of net present value.
No way a Web 2.0 project would survive that. Heck, it would be laughed out of the process by the business team responsible for submitting projects to IT, long before it gets to an IT group for cost estimation! And then, it would be slapped with a huge “new stuff” tax that IT groups place on any project that makes them do something new or different.
In our little corner of the company, we wanted to put in Web 2.0 two years ago. The problem that we faced was this: the portal software we were using didn’t allow REST or SOAP services because of the security model. As a result, we built a “psuedo-service” so that our Ajax-inspired-but-not-directly-derived-and-therefore-expensively-hand-coded web controls could pull down the data they needed when they needed it.
It’s an excellent first step. But did the business want to go the extra step, on the same project, and describe what that psuedo-service was and did, and share that information with our end customers? Nope. That bit was never suggested, by either side.
So here we sit, two years later, with no more of a Web 2.0 story than we had when were first inspired to create one. We got as far as we did, as an IT group, because we didn’t ask if the business actually wanted Web 2.0. The business wanted functionality, and we could deliver functionality in this way. The oversight process let us build it because the “mean politic” didn’t realize that we were changing the landscape. We didn’t tell the funding machine we were trying to build anything radical or new.
On paper, we looked ordinary, creating a “consistent user experience for our customers.” So we got funded. (I had nothing to do with it. I shine in their reflected glory, but I give credit to key individuals inside the team and one or two consultants who believed in new ideas and made them happen). Maybe that is how other IT teams can put Web 2.0 to work… by not using the word.
Do we, as an IT group, have the courage to make the next step, and lead the business to a real Web 2.0 world? Can we convince the brutal, conservative, mistrusting funding process to let a little more innovation to survive? We shall see.
Until then, the Web 2.0 boutique companies will not get a lot of competition from IT.