However one defines "enterprise," what really matters is an organization's culture.
Bill Higgins of IBM and I have been working on an article about DevOps in the enterprise. DevOps is mostly closely associated with Internet giants and web startups, but increasingly we are observing companies we lump under the banner of “enterprises” trying — and often struggling — to adopt the sorts of DevOps culture and practices we see at places like Etsy. As we tried to catalog the success and failure patterns of DevOps adoption in the enterprise, we ran into an interesting problem: we couldn’t precisely define what makes a company an enterprise. Without a well understood context, it was hard to diagnose inhibitors or to prescribe any particular advice.
So, we decided to pause our article and turn our minds to the question “What is an enterprise, anyway?” We first tried to define an enterprise based on its attributes, but as you’ll see, these are problematic:
- More then N employees
- Definitions like this don’t interest us. What changes magically when you cross the line between 999 and 1,000 employees? Or 9,999 and 10,000? Wherever you put the line, it’s arbitrary. I’ll grant that 30-person companies work differently from 10,000 person companies, and that 100-person companies have often adopted the overhead and bureaucracy of 10,000 person companies (not a pretty sight). But drawing an arbitrary line in the sand isn’t helpful.
Data science is hard but it isn’t dark magic.
The question “do you need a data scientist?” came up a lot when I was a management consultant for a global firm that successfully incubated data science within a few enterprise organizations. It’s hard. The discussion is hard and the culture clash for data scientists is hard. Many approach data science as some dark magic from Hogwarts. It’s not. Investigating a hypothesis takes time. Spontaneously generating data and building a model against that data doesn’t work. Understanding who you need and how they will fit into your organization is challenging. Where do we put them? Who do they interact with? What is the hand-off? Who do we structure around the project? How do you execute a project? Even better, how do we make MONEY? Yet, before we go there, perhaps we should step back a bit and think of this as a strategic question. Because maybe you do need a data scientist and maybe you don’t.
How fast can the enterprise change?
At last year’s Fluent Conference, I kept having the same conversation with attendees from large companies. They had come to the show with a mandate from their bosses to figure out how to bring that fast-moving web work into their slow-moving enterprise systems.
I enjoyed some of that same conversation this year, but also a different note: even with management support, making that transition was difficult. Some parts meshed, others were difficult: changes in one place could reverberate through many others. The whole concept of “rapid prototyping” fit badly with a variety of technologies and approaches meant to minimize unpleasant surprises. Even eight years after the advent of Ajax, a variety of server-centric techniques limit the flexibility of front-end developers.
Someone at lunch said that “the technology helps, but the culture matters.” A few others talked about how everyone wanted better front-end work, but thought it could be grafted easily on existing back-end practice. The shiny parts are easy to talk about, but the plumbing is harder.
I was happy to see Bill Scott (@billwscott) of PayPal take on these challenges in his keynote. Bill wasn’t smuggling anything—that would be difficult under the title “Clash of the Titans: Releasing the Kraken.” He was brought to PayPal to change the company, to bring the lean “build – measure – learn” approach. In a risk-averse world, with “a 20-day class on how to use their version of Spring,” Scott had to change the “culture of a long shelf life” (something publishing folks are starting to do as well).
It’s a hard-hitting talk, calling for major change, skunkworks projects, and shifts in both company culture and technology.
Leading eZ Publish advocates look at what lies ahead for CMS programmers and users
There are a variety of options when it comes to content management. We’ve explored Drupal a bit, and in this email interview I talked to some folks who work with eZ Publish. It is an open source (with commercial options) CMS written in PHP. Brandon Chambers and Greg McAvoy-Jensen talk about how the platform acts as a content management framework, how being open source has affected the project, and what we should expect to see coming up for CMS in general.
Greg McAvoy-Jensen is a member of the eZ Publish Community Project Board. He also founded and is the CEO of Granite Horizon, and has been developing with eZ Publish since 2002.
Q: What problems does eZ Publish solve for users?
A: eZ Publish grew up not just as a CMS, but as a content management framework. It sports a flexible and object-oriented content model (an important early decision), and provides developers an MVC framework as a platform for building complex web applications and extending the CMS. Like any CMS it makes content publishing accessible for the non-programmer, and provides an easy editorial interface. eZ Publish does a fine job of separating content from presentation and providing reusability and multi-channel delivery. It targets the enterprise more than smaller organizations, so the software quality remains pegged at high standards, and high degrees of flexibility and extensibility continue to be required.
Q: How you feel being open source has affected the project?
A: Fourteen years on, eZ Systems is still firm that open source is in its DNA. This foundational commitment created a culture of sharing, and it attracts developers who prefer to share their code and to collaborate with others outside their organization for the benefit of their customers. Contributions flow in as both extensions and core code pull requests. The commercial open source model, similar to Red Hat’s, means the vendor takes primary responsibility for code maintenance and development, and derives its profit from support subscriptions, while leaving customizations to its network of certified partners. Because the source is open, organizations evaluating the software can have their developers compare the code of, for example, eZ Publish and Drupal, and make their own determinations. This, in turn, keeps the vendor accountable for the code: eZ engineers program knowing full well that the world can see their work.
Q: What distinguishes eZ Publish from other CMS options?
A: While there may be a thousand or so CMS’s around, analysts typically look at something more like 30 that are important today. eZ Publish fits into that group, most recently by inclusion on Gartner’s Magic Quadrant beginning in 2011. Not all open source CMS’s have a vendor behind them who both provides support and has full control over the code, a level of accountability required in enterprise applications. eZ is a great fit for particularly complex implementations, or situations where there is no assurance that future needs will be simple. And despite the complex customizations developers do with eZ Publish, they rarely interfere with upgrades.
eZ’s engineers recently became dissatisfied with the merely vast degree of flexibility they had built into the MVC framework, so they’ve now moved the whole system on top of the Symfony PHP framework. eZ Publish is now a native Symfony application, the only CMS to utilize Symfony’s full stack. This leverages the great speed and excellent libraries Symfony provides, and makes eZ easier to learn by those who are familiar with Symfony. Some CMS’s require many plug-ins just to get a basic feature set going on a site, but eZ Publish has long included granular security, content versioning, multi-language support, multi-channel/multi-site capability, workflows, and the like as part of the kernel.
Doug Hanks on how the MX series is changing the game
Doug Hanks (@douglashanksjr) is an O’Reilly author (Juniper MX Series) and a data center architect at Juniper Networks. He is currently working on one of Juniper’s most popular devices – the MX Series. The MX is a routing device that’s optimized for delivering high-density and high-speed Layer 2 and Layer 3 Ethernet services. As you watch the video interview embedded in this post, the data is more than likely being transmitted across the Juniper MX.
We recently sat down to discuss the MX Series and the opportunities it presents. Highlights from our conversation include:
- MX is one of Juniper’s best-selling platforms [Discussed at the 0:32 mark].
- Learn if the MX can help you [Discussed at the 1:00 mark].
- What you need to know before using the MX [Discussed at the 6:40 mark].
- What’s next for Juniper [Discussed at the 9:39 mark].
You can view the entire interview in the following video.
Specific ways big data will inundate vendors and customers.
My new book, Disruptive Possibilities: How Big Data Changes Everything, is derived directly from my experience as a performance and platform architect in the old enterprise world and the new, Internet-scale world.
I pre-date the Hadoop crew at Yahoo!, but I intimately understood the grid engineering that made Hadoop possible. For years, the working title of this book was The Art and Craft of Platform Engineering, and when I started working on Hadoop after a stint in the Red Hat kernel group, many of the ideas that were jammed into my head, going back to my experience with early supercomputers, all seem to make perfect sense for Hadoop. This is why I frequently refer to big data as “commercial supercomputing.”
In Disruptive Possibilities, I discuss the implications of the big data ecosystem over the next few years. These implications will inundate vendors and customers in a number of ways, including: Read more…
Android software development at a crossroads
Apps have to get bigger and more ambitious. A key question for the developer community is how do you create big, integrated, multi-functional, configurable apps for the mobile enterprise? Curiously, Facebook is providing some answers by not using HTML5 and not attempting to make a cross-platform app. Go native, go big, and go deep.
Facebook Home is a harbinger of serious mobile apps
Facebook Home has earned positive reviews—in many cases from reviewers who had tired of Facebook and the intrusiveness of Facebook’s privacy policies and practices. Facebook Home is an example of a new kind of Android software development. It spans a variety of functions as a suite of cooperating software. It uses Android’s intent filters, high-level interprocess communication (IPC), shared databases (
ContentProvider components) and remote APIs to bond together a software product that replaces many of the standard parts of Android—as they are meant to be replaced.
Facebook Home isn’t some kind of rogue hack, nor is it a “fork” of AOSP, as Kindle Fire is. Facebook Home is a tour de force of correct Android application architecture. It takes over your phone, interface by interface, always playing by the rules, and it does so for justifiable reasons: for putting Facebook’s functionality everywhere you want to perform communications and social media functions.
Moreover, Facebook Home simply can’t be done on iPhone. iOS has a specific vision of apps that is separate from system software, while Android’s frameworks are the basis of both applications and system software. Facebook Home was built with this difference in mind: It replaces key elements of the Android system user experience. It is a suite of communicating apps. The word “app” doesn’t sufficiently describe it.
It's not about IT buying, but about making data work for you. Learn more in the Big Data in Enterprise IT program at Strata California.
In a world where technology and business are evermore intertwined, IT leaders aspire to key roles in their organizations. Sadly, industry conferences can lag behind, assuming IT is all about making the right buying decisions.
Not so at Strata.
Our approach is to take a view of data for business that centers around the problems you need to solve. The excitement around big data isn’t really about large volumes of data, it’s about smart use of data. It’s about using data to make your products better, help you be significantly more efficient, and create new products and businesses.
Getting the most from big data and data science is a lot more than a software choice. The business aims come first, and a good understanding of the problems you want to solve. Then you need to understand the capabilities of the technology and where data science can be best applied. Finally, you need to know how to run successful data projects, and how to hire and manage data teams.
Working with analytics and BI expert Mark Madsen, I’ve compiled a day-long program at Strata called Big Data in Enterprise IT that will take you through big data strategy, the issues of managing data, and how data science can be used effectively in your organization. Read more…
What's interesting isn't software as a thing in itself, but software as a component of some larger system.
One of Marc Andreessen’s many accomplishments was the seminal essay “Why Software is Eating the World.” In it, the creator of Mosaic and Netscape argues for his investment thesis: everything is becoming software. Music and movies led the way, Skype makes the phone company obsolete, and even companies like Fedex and Walmart are all about software: their core competitive advantage isn’t driving trucks or hiring part-time employees, it’s the software they’ve developed for managing their logistics.
When I look at what excites me, I see a much bigger world than just software. I’ve already argued that biology is in the process of exploding, and the biological revolution could be even bigger than the computer revolution. I’m increasingly interested in hardware and gadgetry, which I used to ignore almost completely. And we’re following the “Internet of Things” (and in particular, the “Internet of Very Big Things”) very closely. I’m not saying that software is irrelevant or uninteresting. I firmly believe that software will be a component of every (well, almost every) important new technology. But what grabs me these days isn’t software as a thing in itself, but software as a component of some larger system. The software may be what makes it work, but it’s not about the software. Read more…
Heavy data, open source strategies for businesses, and collaborating on code.
This week on O’Reilly: Jim Stogdill said data is getting heavier relative to the networks that carry it around the data center; Simon Phipps revealed open source community strategies relevant to the enterprise; and Team Geek authors Brian Fitzpatrick and Ben Collins-Sussman discussed the importance of developer collaboration.