by Eric Knipp | August 2, 2013 | 5 Comments
I had a great week at Gartner Catalyst where I spent time with many clients and got to catch up with friends old and new. Gartner analysts speaking at our conferences not only present on-stage, we spend a large amount of our time in one-on-one sessions with attendees. During these one-on-ones, we try to help our clients answer their most important questions and solve their most challenging problems. As you can imagine, at a conference with 1500+ attendees, there are a lot of different questions to go around. My most popular client question came down to, “How do we select and implement API management capabilities?”
While working with attendees to answer this question, I noticed a concerning trend. Attendees interested in talking to me about criteria to use in selecting an API management product often could not articulate an API strategy; even worse, few had spent much time considering the importance of API design. I definitely felt the focus was more on buying a solution, rather than understanding the fundamentals of API strategy, design, delivery, and management.
Rolling Without a Strategy Will Cost You Money
Why are you building your API? A lot of people tell me they need the API because of a particular mobile project (or at least, that’s how they’re funding the development of the API). When I ask about the long-term plans for the API, I get a lot of blank stares. That’s a problem.
Your API might really just be for that one mobile app. But I doubt it. The real value of an API lies in its ability to provide access to many new channels that were previously very difficult to reach – mobile, social, third-party developers creating new apps, and so on. On top of that, your API might be relevant in a partner integration scenario, or even for running your own non-mobile Web applications. If you make design decisions in a vacuum – based on the presumption that the API is just for the mobile app you’re currently working on – you will paint yourself into a corner.
Maybe it is worth being painted into that corner because of the learning you’ll get by executing quickly. That’s a position I can understand and respect. But it isn’t one that I endorse taking by accident; it will cost you money down the road. So, start by having an API strategy that takes explicit positions on what the API is and is not intended to do and how the API strategy aligns with your business strategy. My colleague Gordon Van Huizen has written a great document on the topic.
API Design is Important
I’ve written about it extensively, but just to make it clear, one more time: API design doesn’t require you buy any new technology. You should begin your API design before, or at worst, in parallel with your exploration and purchase of an API management solution.
Without an explicit process for API design, the temptation to turn it into a supply-side exercise is great. The odds of building the wrong thing become much higher. Without an understanding of what a good API looks like for your audience(s), you’ll also have a harder time prioritizing capabilities available in the API management product space. Loosely translated, this means that in the absence of understanding, you’ll substitute money and pay for a bigger, heavier, and more expensive API management platform than you really need. Skipping API design is bad on a lot of fronts.
The first step in doing an API well is to create a well thought-out strategy. The second step is to do a great job with design. Please don’t skip these steps.
Category: Uncategorized Tags:
by Eric Knipp | July 28, 2013 | 2 Comments
A little levity before we start off Gartner Catalyst. A b-school friend of mine pointed out that as we go through life in the US, there’s a bit of a love/hate relationship with getting “carded” for alcohol purchase. I realized immediately that this relationship bears a striking resemblance to something we know well at Gartner..
While I won’t be giving a presentation on this topic, I still hope to see you at Gartner Catalyst.
Category: Uncategorized Tags:
by Eric Knipp | July 26, 2013 | Comments Off
I’ll be in San Diego next week at the annual Gartner Catalyst conference. “Convergence” is the theme this year. Specifically, the convergence of mobile, social, and information – all backed by cloud – to bring about new opportunities and challenges for enterprises and IT professionals alike. My team is presenting a “virtual track” of application architecture and development goodness. Our presentations explore:
- How to develop applications for delivery to mobile devices and the desktop
- How to select the optimal development frameworks
- How to improve your development methodology in the face of a volatile technology climate
- New approaches to software architecture
- How to leverage the cloud in your custom-built applications
I hope you’ll join us. If you can’t, I’ll be tweeting as often as I’m able.
I’m still hiring one more analyst for our Egham office. If you’ve got well-informed opinions on software development, great presentation and writing skills, a passion for telling people what you believe about IT, and you live in the UK, please take a look at the job description. Feel free to drop me a line if you want to ask a few questions about the role.. and if you’re just positive you want to be a member of our team, go ahead and apply!
Category: Uncategorized Tags:
by Eric Knipp | May 20, 2013 | 2 Comments
Large enterprises are very interested in the PaaS value proposition, but much less interested in making strategic commitments to public PaaS. This is generally true of public cloud overall. Only in the SaaS area do we see substantially less durdling by our enterprise clients. My working theory is that this is mostly because popular SaaS options are a cut above their packaged counterparts in capability, usability, and spending flexibility; plus, the business won’t take no for an answer. The differentiation available in some SaaS is too alluring to ignore.
The same has so far not proved consistently true for public cloud IaaS and PaaS. To be sure, these areas are growing; recent financial analyst AWS revenue estimates are impressive indeed. Step back a minute and let the reality sink in that the market for cloud services is at least as large as the existing market for enterprise IT (hardware, software, and hosting) itself – then, the AWS number doesn’t look nearly as big. There’s still a lot more cash burned in traditional data centers than there will be in public cloud IaaS and PaaS for some time. We can argue until we’re blue in the face about whether that’s a good thing or not, but it is what it is…
And, what IT is, at least with respect to PaaS, is a growing enterprise desire for Private PaaS. Mock it at your peril – just like private cloud, the ship has sailed and will be pulling into a harbor within an enterprise data center near you. The value proposition for Private PaaS seems compelling – an increasing number of stories suggest that Private PaaS can get you both reduced operational burden and higher developer productivity. As anybody who reads my blog knows, I think that developer productivity is a big deal.
Private PaaS is coming, but how do you adopt it if you’re the “classic” enterprise IT organization with a diverse portfolio of home-grown applications and integrations, running on what I will for the purposes of this discussion call “classic” middleware? Do you wait around until 2015 (or later) for Java EE 8 to bring you the cloudy features you’re looking for, now that we know for sure that Java EE 7 won’t have any? Or, do you just wait for your preferred IT megavendor to get around to offering you a for-real, multitenant, cloud-native, Private PaaS that goes beyond simply slapping a pre-built middleware stack onto a virtual machine?
If for your enterprise, technology is just a necessary evil, a cost of doing business, then the answer is probably yes: wait until the early movers have wrung all the new value from the PaaS model and pick it up when prices are cheap and the systems commoditized. My guess is nobody reading this blog feels that way about IT.
If for your enterprise, technology is expected to expand the business, to serve as a differentiator in your market, to deliver what MBA types like to call competitive advantage – then Private PaaS can no longer be ignored.
Category: Cloud Cloud Application Platforms Private PaaS Tags:
by Eric Knipp | May 17, 2013 | Comments Off
I am heading back to Germany after a few fun days in London at the Gartner AADI conference. We had a good show, with a high level of attendee enthusiasm and interaction. I had good 1-on-1s and a very engaged (if small) set of workshops on .NET in the cloud, private PaaS, and cloud application architecture. I have a few quick takes on my experience.
Professional Effectiveness is a Big Issue
At lunch today I presented to a set of interested attendees on Gartner for Technical Professionals (GTP) – our value proposition, resources available to clients, and so on. In a nutshell: as GTP analysts our mission is to accelerate time to competency for the solution architects using our material. When you get a new project, we provide objective advice and how-to guides that will shorten your effort’s time-to-value.
Among our technical coverage areas (which include application platforms, data centers, cloud computing, mobility, social software, and so on) we also include one focused on “soft skills” which we call Professional Effectiveness. The idea here is to help the propellerheads communicate more effectively, manage up better, manage their careers more competently and just generally function at a higher level than their purely technical skills might suggest. The attendees to our GTP lunch focused laser-like on this topic, sharing with us numerous challenges around staff development. This is a great way to leverage GTP research and I was glad to see it. As a broader trend, I think it bodes well for the next generation of techies to have engaged managers who care deeply about professional development. And, it’s neat to see how our PE agenda is helping to shape at least a small number of the next generation of IT Leaders.
.NET Shops are Interested in a Hybrid Cloud Future
My workshop on “Choosing .NET Platforms for Cloud Computing” was my best session of the conference. Workshops are a great forum, providing an extended time (90 minutes) for analyst expository on a topic, incorporating several exercises and group discussion. The intimate environment of a large boardroom makes for a crackling atmosphere when the audience is truly engaged, as the attendees of my session were. We worked through the framework I developed for my soon-to-be-published paper on assessing .NET alternatives.
Capacity utilization rose to the top as the most important consideration among session attendees, followed closely by reduced time-to-market. Further, all reported very strong interest in hybrid cloud deployment models that preserve the enterprise’s option to choose runtime location at a later date. Basically, .NET shops represented in my session are looking to get elastic, cloud-native solutions out the door as fast as possible but without compromising portability by mitigating vendor lock-in as much as possible (or as much as is possible once you’ve already locked yourself to Microsoft by virtue of the choice of .NET). These were interesting findings for me, and I didn’t see as much desire for lift-and-shift style cloud adoption as I expected.
API Management is Really Popular
As usual, 1-on-1 topics were diverse and interesting, but the most often asked question had to do with Web APIs. API management came up frequently but it was good to hear more clients asking about API design issues, which I think are so much more important than which API product suite you end up buying (or consuming as a cloud service). API management has been a hot space lately and there was no shortage of vendor representation at the event, but attendees were also very interested. I saw a great appetite for my API design paper – which I hope will prevent some GTP clients from making major design mistakes.
Did you attend Gartner AADI? What were your most important take-aways?
Category: Uncategorized Tags:
by Eric Knipp | April 30, 2013 | Comments Off
According to Forbes, the “API market is on fire“. My conversations with Gartner clients on this topic would seem to confirm the article’s top line. In the first quarter, only application PaaS crowded out APIs as the most popular topic for my client dialogues (and that’s counting the fact that for the month of March, I picked up all of a departing analyst’s PaaS client calls). I have covered APIs at Gartner since mid-2009 and have seen a steady growth in client interest. If you’re an API aficionado, that’s great news.
Now, for the not-so-great news. A great many API initiatives from non-technology companies suffer from poor, or entirely absent, design. Beside the usual REST-vs.-SOAP impedance mismatch that experienced object-oriented developers have to work out, there is a darker, more sinister force causing problems with enterprise-created APIs: laziness.
We want to get our APIs out the door as fast as we can so that we can start leveraging them, monetizing them, seeding the market with them, powering our mobile apps with them, and so on. In our haste to get the API to market, we can easily be tempted to take a short cut – simply expose our existing domain models (which include our databases, web services, SOA repositories, and so on) to the world with a thin veneer of REST generated by some development tool. Presto! API. Not so fast.
The practice of “domain model dumping” is sure to be a scourge of poorly-designed APIs in the coming years, especially if the recent acquisitions have lit a fire under the hindparts of previously oblivious CIOs and CTOs. As the API landscape becomes increasingly crowded, developers will discover that they have several (or even many) functionally identical APIs to choose from – so don’t give them a reason to avoid yours. Gartner’s approach to API design focuses on several key factors, in an approach we call Consumer-Driven API Design.
A Consumer-Driven approach decouples API design from the underlying data model it exposes to its intended audience. It forces the design team through a repeatable and transparent methodology that produces demonstrably better outcomes than an ad-hoc and hackneyed approach. And the best part: you don’t even need a fancy-pants API management product to do it. If you’re interested in getting better at API design, as a Gartner for Technical Professionals client you can have a gander at my document on the topic, and follow it up with a conversation with me.
Finally, I am still looking to hire a couple of great analysts in the UK. Click here if you’re interested!
Category: Web APIs Tags: API
by Eric Knipp | March 20, 2013 | 2 Comments
While attending the Gartner BI Summit in Grapevine, TX yesterday I had a meeting with a client that made me facepalm a little.
The client in question was telling me about his need to educate his development staff in a number of critical areas, ranging from application lifecycle management, to data access patterns, to SOA governance, and on. The organization he works for is in the middle of a major hiring binge, and within the 200+ IT group there are few technologists with more than a year’s experience inside the company. This is a challenging situation, even when you can assume (as you should be able to) that most of your programmers know the difference between a library and a service! Many of the programmers in this organization prefer to create code libraries rather than services, and most of them don’t understand why they should build a service instead of a library. So, let’s get into that here.
In a nutshell: a library is shared code that you compile into your application. A service is a shared capability that you access from your application:
I am a (mostly) strong proponent of relying on services whenever possible, instead of building custom code libraries for inclusion in many programs. The agility, reuse, and transparency benefits of a service are just too hard to ignore. Having said that, I recognize that there are specific cases where creating libraries could be more appropriate:
- When you’re building an application that will be deployed to a device with inconsistent network access (making remote service consumption unreliable)
- When you’re building an application that will be hardened with wrapper technology for security reasons (and network access to remote services is seen as an unacceptable compromise)
A few more details that I quickly came up with which you might find worthwhile (let me know if you have any to add here):
||Executes locally inside of your program
||Executes remotely outside of your program
||Distributed/deployed with your program
||Exists independently of your program
||Internal compilation dependency for your program
||External consumption dependency for your program
||Cannot change unless you recompile/redeploy your program
||Versioned independently of your program
||Instance used in your program is used only by your program
||Can be shared with many remote programs
||Access to library routines cannot be mediated
||Access can be mediated for security, QoS, or other reasons
||Access to library routines cannot be audited
||Access can be logged and audited by a mediator
||Program cannot be inadvertently broken by a dependency change
||Many programs can benefit from service reuse and improvement
||Programmers can easily understand all project dependencies
||Service mediation can provide many benefits
||Compiled program is entirely self-contained
||Service-based design is more flexible to unanticipated changes
||Library improvements can only be used at program recompilation
||Service oversubscription creates an availability bottleneck
||Multiple versions of the same library can be used in many programs
||Service mediation is a black art to most programmers
||Patterns of library consumption are not clearly visible at runtime
||Services may not be modeled with the right level of granularity for reuse
A final word.
Ever thought about being an analyst? You’re in luck! I am hiring two analysts in the UK (preferably the Greater London area) to join the Application Platform Strategy (APS) team. If you think you’d like to cover application design, development, and delivery for fun and profit, have a look at this link.
Category: Applications Programming Tags:
by Eric Knipp | October 9, 2012 | 14 Comments
PaaS reduces the incremental cost of a custom application. Because demand for custom applications is elastic with respect to price, maturation and proliferation of PaaS will drive growth in custom application development.
I’ve been engaged in a discussion with a colleague about the relative importance of application development vs. application delivery. This might seem like splitting hairs but I assure you, it is not:
Application Development - Designing, coding, testing, implementing, and maintaining a custom software solution over time.
Application Delivery – Selecting, implementing, and maintaining a software solution over time. This may or may not include application development and that development may be part of a complete custom system or it may simply be coding a few connectors as part of an integration effort.
The crux of my colleague’s hypothesis is derived from a simple and intuitive idea: the proliferation of cloud services represents the biggest outsourcing maneuver in IT history and will lead to the decline of internal Application Development because “the business” will instead choose from a smorgasbord of SaaS offerings that model every conceivable business process. Implicit in this assumption is the decline of enterprise IT in general and operations in particular (if you’re using SaaS you don’t much need a data center). This is future state stuff, 3-5 years down the road at least. And even then hybrid IT will be around for a while. Let’s continue without getting into the hybrid private/public cloud war zone, shall we?
I have a difference of opinion. While I don’t debate that “the business” will have more “packages” to choose from (loosely referring to packages as both traditional deployed solutions and cloud-sourced SaaS), I also believe that enterprises will be developing more applications themselves than ever before.
The reason why I believe a golden age of enterprise application development is upon us is Economics 101: elasticity.
A good or service is considered to be highly elastic if a slight change in price leads to a sharp change in the quantity demanded or supplied.
Gartner analysts spend time on the phone talking to clients. A lot of time. Not once have I or my close colleagues ever heard a client say any of the following:
- We don’t have a backlog of desired applications with provable ROI.
- We can’t find any applications that we think are a good idea but without provable ROI.
- We don’t need any new applications. We’re all out of ideas!
No, if you’re in an Application Development or Application Delivery organization you’ve never heard this stuff. In fact, you’ve heard the opposite and your daily life is at least in part about
ignoring managing demand. The business doesn’t stop making new demands but rarely does it ask for existing stuff to be decommissioned.* Its a continuous effort to get the resources to build the stuff with provable ROI that has by hook or by crook managed to ease its way to the top of the prioritization pile. The fact is, I can’t think of a single organization that doesn’t have a big backlog of applications it’d like to get delivered.
Furthermore, the backlog is even bigger than you think. By default, people self-edit and don’t put forward ideas for which they know there is no value proposition. If it doesn’t have a positive ROI, it doesn’t even get on the list.
But what if the incremental cost of a new application were to fall – dramatically? What would happen then?
Application Development and Elasticity.
I submit that the demand for applications is elastic with respect to price. Meaning that as the incremental cost of a new application falls, enterprise demand will increase. I submit as evidence:
- The fact that application delivery prioritization in most organizations has ROI as the #1 driver after compliance.
- The fact that applications without a positive ROI don’t even get considered (unless compliance).
- The fact that SaaS and Web startups have exploded since the incremental cost of delivery decreased (thanks to IaaS and then PaaS).
The last point I find the most instructive because it is the one that my colleague is arguing in favor of. He believes that precisely because SaaS is so abundant and cheap there will be fewer applications developed in-house in the future. I say just the opposite: the drivers that make SaaS cheap also reduce the incremental cost of applications developed in-house.
PaaS and Cheap Development.
Quite simply, a good PaaS makes development cheaper. That’s why you see so many startups using PaaS as the market matures. PaaS is all about outsourcing the plumbing work so that developers can focus on building the business logic and important features that differentiate one application from another. Let me say that very clearly:
The single best way to reduce the cost of application development is to improve the productivity of your application developers.
The story of platforms the last decade is one of increased developer productivity. Its the main reason why we have Ruby on Rails, Groovy on Grails, Node.js, and on and on. It’s why we have cross-platform development tools like Appcelerator, Sencha, PhoneGap, and on and on. It’s why we pay certain developers more than others (well I guess not everybody does that – which is a big mistake but that’s a conversation for another time). You know in your gut that a highly productive developer isn’t just a little bit more valuable than an average developer – he’s ten times more valuable than the average developer (and more recent research puts this even higher). Productivity is the single most important area of cost optimization for application development today. The PaaS value proposition is almost completely focused on productivity.** It is a match made in heaven.
Build, Buy, Borrow, Steal, Rent, Etc.
But back to the sourcing question. Because the perceptions that drive enterprises to develop their own applications aren’t changing, I expect to see even greater demand for new custom applications than in the past. What are those common perceptions?
- Available packaged solutions are not suited for my company or industry
- I can do it cheaper or better with my own development staff
- My business processes are top secret and there’s no way I’m handing them to an outsider
I’m not debating whether those perceptions are right or wrong. They are what they are. And they haven’t changed in forever, and the cloud isn’t going to change them either. Let’s call them human nature. Taking into consideration human nature and economics 101, the outcome seems pretty obvious:
- PaaS reduces the incremental cost of a custom application.
- Enterprises have a backlog of applications without adequate ROI under old cost assumptions.
- Demand for new applications will grow as cost assumptions shift downward.
It’s PaaS-O-Nomics. As PaaS matures we will see more applications developed, period. Whether from Web startups, SaaS providers, or enterprise IT organizations – it is a rising tide that lifts all development ships. So the correct answer isn’t Application Development vs. Application Delivery – it’s both.
I’d love to hear your opinion. Am I right? Am I wrong? Is there another story that I’m entirely missing?
* Shameless plug: Val Sribar and I will be presenting on the topic of preparing to address future demand while simultaneously addressing the existing application portfolio in our Apps 2020 presentation at Gartner Symposium.
** I recognize that there are numerous other good reasons to consider PaaS, including geographic distribution, quality of service, fault tolerance, and so on. But for most organizations productivity should be the only thing they think about because it is all you need to think about to make the right decision, public or private.
Category: Cloud Cloud Application Platforms Programming Tags:
by Eric Knipp | August 27, 2012 | 4 Comments
I just returned home to Dallas after participating in my first Gartner Catalyst conference. The event was impressive with tons of content and almost 1800 attendees on-site, not including Gartner staff. I’ve presented at a number of Gartner Symposia and Summit events and I was struck by the deep level of attendee engagement at Catalyst. Our attendees are in the midst of mobile, cloud, and big data initiatives and it was great to hear about their experiences and challenges in my conference sessions, roundtables, and of course copious analyst-attendee 1-1 sessions. As I cover Web APIs in depth these days (and to a lesser degree mobile development) I thought I would share my top 3 “aha” moments from the conference, based on attendee feedback and questions:
The mobile bone is connected to the Web API bone. I’ve advised for some time that clients consider a Web API as the first step of a mobile development initiative, in particularly one that depends on connections to existing back-end systems that have not yet been ‘mobile enabled’. My conversations at Catalyst make clear that practitioners have come to this conclusion as well and are embarking on a variety of Web API initiatives in support of mobile app enablement. I have one further piece of advice beyond establishing a Web API at the outset of a mobile app initiative – don’t treat it as just a part of or infrastructure for your mobile app, but as a product in its own right. Done well, your Web API will power multiple mobile apps, partner integrations, and Web applications, but that requires a commitment to design that is easy to skip if you think you’re just doing it as a one-shot deal for a single app.
The majority of Web API initiatives leave versioning for later. I believe this is a dangerous idea for a variety of reasons. First and foremost, if you run just one version of an API you risk introducing a breaking change anytime you extend it. While you can potentially work around this with a very robust set of test cases (which I would strongly encourage), it is easy to paint yourself into a corner when you are unable to fix a bad implementation that seemed like a good idea at the time. Over time your code gets crufty and filled with technical debt and eventually you might be forced to declare bankruptcy – basically starting over with a new Web API and disenfranchising all of your existing API consumers all at once. On the flipside, versioning isn’t something you should automatically commit to. Running multiple versions has its own costs – multiple code bases and the overhead that comes with that, multiple groups of API consumers and the service levels you must provide them, and so on. My advice on this one is just to take it seriously – if you choose not to decide, you still have made a choice.
Consuming Web APIs from external providers can be a serious challenge. If you deal with a lot of niche players with screwball ideas about Web API design you have your work cut out for you. While the cloud and social leaders like Facebook, Salesforce.com, Twitter and so on get a lot of pub for the quality of their Web API designs, there are myriad small SaaS providers who treat the Web API as an afterthought. Understandably, they instead spend their R&D dollars on slick GUIs and worthy business processes which the business selects without even considering integration. If you are unlucky enough to be asked to integrate some of these niche apps with your existing systems it isn’t going to be a lot of fun, especially if you use the brittle point-to-point style of integration. My advice is that you consider using a gateway to shield your applications from direct exposure to external Web APIs.. this will provide you a single logical layer to deal with and the better API gateways on the market can do some basic transformations and quality of service improvements that allow you to homogenize the interfaces somewhat, which can be very useful if you’re part of a larger team that delegates the business logic implementation to different hands than the actual service consumption/integration.
Web APIs are growing in popularity and that makes it a fun time to cover them. Web API gateways, servers, and management technologies are proliferating at the hands of cloud and product vendors alike. If you’re a Gartner for Technical Professionals client I would love to talk to you about it.
Category: Web APIs Tags: API
by Eric Knipp | March 30, 2012 | 2 Comments
It is a bittersweet thing to say goodbye to a great team member while opening the door for a new, potentially great team member. Sean Kenefick is leaving our team to pursue entrepreneurial interests. Sean has done a great job covering ALM, DevOps and other software development life cycle issues. I wish Sean all the best in his new focus and I hope that our professional paths will cross again.
We now have an opportunity to bring a great newcomer to the Application Platform Strategy (APS) team. Our team covers every aspect of application development (AD) you can imagine – from middleware, to mobile, to user experience, application architecture, cloud platforms, business process management, SOA, agile and SDLC practices, and so on. If you’re a solution architect seeking guidance on AD-related technology and practices we are the best group in Gartner to speak with. We’re looking for one more great analyst or analyst wannabe to fill out the team.
We’re not looking to “replace” Sean. While there’s clearly an opportunity to address a gap in our coverage, we’re looking for the “right person” more than the “right coverage”. When we’re qualifying candidates, we will closely examine:
- Depth of practitioner experience
- Customer-centric thinking
- Demonstrated willingness to take a position, articulate it well, and engage others in doing so
- Ability to write, including technical documentation, books, and articles
- Ability to verbally communicate, including presentations for large and small audiences
- The right temperament and a heavy dose of intellectual curiosity
If you’ve always wanted to be an analyst but never had the courage to ask, this is your opportunity. Please use the below link to learn more about the job, and feel free to contact me or Anne Thomas Manes directly if you want to find out what being an analyst is all about.
Application Platform Strategy Analyst – Gartner Research
Category: Uncategorized Tags: