This layer is self-explanatory, except insofar as it is anchored in the humanities proper, rather than information technology. Two representative texts are perhaps Dan Cohen and Roy Rosenweig's Digital History: A Guide to Gathering, Preserving, and Presenting the Past on the Web [Cohen and Rosenzweig 2005] and Matthew Kirschenbaum's Mechanisms: New Media and the Forensic Imagination [Kirschenbaum 2007]. Both texts are firmly grounded in the analog humanities, and are effectively attempts to graft the digital humanities onto the main trunk of the tradition. Although a non-technical audience might find them intimidating, to most digital humanists they represent readable and penetrative overviews of the field. John Willinsky's book The Access Principle [Willinsky 2006] also fits into this layer (as well as the “Philosophy / Ideology” layer – see below), as do the essays on the Centre for History and New Media’s essay list.[5] Digital Humanities Quarterly and journals like Vectors and the Journal of New Media and Culture fill out the layer, as do practice-oriented sites like the Stanford Humanities Lab and machine-oriented sites like MIT’s Media Lab. Indeed, the last 5 years have seen a marked increase in essays and websites that seek to define methods and theorize purpose for the field.

This is where the digital humanities were born, where I would hope the bulk of the activity still occurs, and where their core future lies. A decade or more ago, publications like Project Gutenberg, Paul Halsall's Internet Modern History Sourcebook , Arts and Letters Daily , the University at Buffalo's Electronic Poetry Centre, the University of Virginia's The Valley of the Shadow and the Center for History and New Media's Liberty, Equality, Fraternity: Exploring the French Revolution , provided clear evidence that good quality humanities work could be presented online, and that the internet offered a radical new channel for humanities output. Similarly, the arrival of Wikipedia may have provoked widespread panic about the quality of online content, but it is also the perfect example of how content-centric the digital humanities are. Above anything else, the new media requires content, just like the old media. This will only increase as the publishing industry transition more of their assets into the online world, new delivery platforms like the iPad proliferate, and universities come to realize the cost-efficiencies implicit in the online content model. When blogs and social media are included in the Content layer, it becomes clear that, for the digital humanities as for the rest of the online world, “content is king”. There is little reason to launch into an extended discussion of this layer, because it is where most of us work on a daily basis.

The Tools and Applications layer is another crowded space, but unlike the content layer, it is of little interest to mainstream humanities scholars. This is the layer where technical expertise takes over from content development, and in the digital humanities this normally amounts to development effort that aims to facilitate production and dissemination in the Content layer. It would be possible to argue for a separate Tools layer at this point in the structure, but I'm describing a single layer because tools and applications are bound by the Software Development Life Cycle: they are developed in code and inevitably reference each-other. For instance, at this layer we not only have operating systems like Ubuntu, Snow Leopard and Windows, but tools like Zotero and Monk and web applications like Omeka, not to mention the IDEs, code repositories and project management tools used to build them. Note that at this tier we also have the languages and frameworks used to write the applications: primarily .php and .css but also perhaps application technology stacks like Zend or web development frameworks like Ruby on Rails or Vaadin. Common content management systems like Drupal, Joomla, Moodle and Wordpress would also fit into this layer, as do developing web services like Google Maps and platforms like Hypercities. As the digital humanities scale both vertically (in size) and horizontally (into the “web of things”) we may find Java being used more, and there is no reason to deny at least the possibility of DH-friendly languages appearing in the future, like Cobol and Fortran in the maths and sciences. This is a messy layer. It is essentially the engine-room of the digital humanities, churning out products that enable the growth of the discipline beyond 'mere' content creation. It actually needs a sub-model of its own. I suspect that most digital humanists would argue that, for the moment at least, this is the most crucial layer because this is the layer that will be filled completely by the large corporations if the digital humanities fail to expand into mainstream academia.

The Middleware layer could be the next area to be “built out” by digital humanists. I note this possibility because middleware will presumably provide a key layer in the growth of the semantic web and the web of things. Significant projects like SUDAMIH are already underway, focusing on the development of humanities-centric data management infrastructures. It could well be that the engineering of this layer (and “engineering” is the defining term to use for this layer, just as “development” is the defining term for the layer above it) is left to commercial organizations who provide “plug-and-play” middleware tools, but I suspect a lot of work will be done by computer scientists working in tandem with humanists, as with SUDAMIH and Project Bamboo. It isn't as though digital humanists are going to need specialist application servers or other similar products, but there are fascinating questions around the development of, say, an enterprise service bus (ESB) to facilitate data interchange across connected humanities infrastructures. With that in place we would presumably be one step close to a global Service Oriented Architecture (SOA) for the discipline. Whether this is possible or even desirable at an international level is beyond me, and the term “middleware” does tend to escape precise definition, but it surely raises some interesting questions. Organizations like the Joint Information Systems Committee (JISC), Digital Research Infrastructure for the Arts and Humanities (DARIAH) and Coalition of Humanities and Arts Infrastructure Networks (CHAIN) are best positioned to investigate these questions, in combination with projects like SUDAMIH that are developing both systems and expertise. It will be interesting to see whether they view generic web middleware as adequate, or whether we need to put some effort into ensuring that the various international digital humanities systems can function at an inter-connected, global level. From their websites it appears they see some room for growth at this layer, even if it remains in fairly specialist, circumscribed areas. Defining the standards for the semantic web is one thing; ensuring our myriad legacy systems are interoperable is another thing altogether. The determining factor in the development of this layer will be whether the digital humanities' emerging Governance bodies (see below) decide that normalization is required to enhance interoperability across disparate infrastructures, or whether – as is perhaps more likely – a more loosely federated model is required, with an emphasis on clear articulation of standards and frameworks to prompt increasing alignment over the long-term.

Our large public sector libraries have traditionally provided the most in terms of standards, stemming from their centuries old investment in classification and metadata, and their now decades-old move into the digital world. Like Governance, the Standards layer provides a crucial vertical structure to support the core Infrastructure, Middleware, Tools & Applications and Content layers. I have no empirical evidence, but my feeling is that Europe-based digital humanists seem more focused on this layer than US-based practitioners who tend to produce applications and content, and engage with social media, undoubtedly due to funding priorities. It's interesting to note that Project Bamboo have discussed not being “involved in creating standards, but rather in helping creators express their work”. Their notes point out the risk of “too much normalization” and “obstructing standards development”  [Project Bamboo 2008]. This is understandable, especially in terms of TCP/IP protocols that can be left up to network specialists (and could be viewed as being part of the Middleware layer), but as I've noted above, digital humanists need to remain aware of the issues and perhaps identify areas where we can contribute in an efficient, focused manner. Following their discussion, Project Bamboo decided on an eminently sensible approach:

• articulating, documenting, and demonstrating benefits that would accrue to use of a specific standard
• adopting technical standards as necessary for internal Bamboo operation
• endorsing or recommending domain-specific technical standards (EAD, TEI, METS, VRA, etc.) which have methodological impact for scholars; also, basing higher levels of functionality or interoperation on the (optional) use of such standards
• communicating and raising awareness concerning the softest kinds of standards: e.g. “business practices” such as work flow, project management
• recommending best practices at all levels
• articulating the value of standards adoption for the community
• acting as a focal point for the humanities community's representation on technical standards bodies, to ensure that humanities perspectives are represented in the future development of these standards

[Project Bamboo 2008]

This approach leaves standards development up to the likes of those involved in initiatives like Dublin Core metadata and the Text Encoding Initiative and correctly places TCP/IP development outside their sphere of interest, while still providing an oversight and educative function for digital humanists.

The digital humanities have no over-arching governance framework, which perhaps accounts for the slight lack of clarity amongst the discussants on Standards at Project Bamboo, who seemed to place TCP/IP middleware protocols in the same bucket as metadata standards, before discarding them again. Like Standards, the Governance layer provides a critical vertical structure to support the proper functioning of the core Infrastructure, Middleware, Tools & Applications and Content layers. This layer has only very recently started to be built out. Although not all directly related to the digital humanities, Our Cultural Commonwealth: The Report of the American Council of Learned Societies Commission on Cyberinfrastructure for the Humanities and Social Sciences [ACLS 2006], Peter Bradwell's Edgeless University [Bradwell 2009], and Cathy Davidson and David Goldberg's The Future of Learning Institutions in a Digital Age [Davidson and Goldberg 2009], all present overviews that could broadly inform future governance models: we are at the stage of initial analysis and exploration. Bodies such as DARIAH, CHAIN, JISC and Project Bamboo clearly have an important role to play in this layer too. The appearance of publications exploring the field, and the growth of organizations focused on governance and the facilitation of global interoperability is heartening. It suggests that the last layer in an enterprise model is beginning to be filled out and promises the level of co-ordination – or at least communication – necessary to the health of the broader system. Governance of the digital humanities is a thorny issue, however. It will not, and should not, be akin to the governance of an enterprise IT system: the field is too broad, the parties too disparate in their priorities, and the participants have a healthy disregard for processes and frameworks derived from the government and business worlds. Standard enterprise governance frameworks like ITIL and TOGAF are useful, but were designed for fundamentally different purposes than those of the digital humanities. At a philosophical level there will undoubtedly also be concerns about the intellectual lineage of such frameworks, based as they are on Tayloresque efficiency-maximising systems that are anathema to much of what the traditional humanities represent. But herein lies the problem: the digital humanities are fundamentally tied to the systems that enable the practice itself, and as the discipline grows so too will the complexities involved. It makes sense to pick models that have worked for other undertakings involving complex IT systems and apply them, critically, to our own. Perspectives like this should remind us that the health (and therefore viability) of the system as a whole relies on a balance between its component parts: the enterprise view isn't so much a normative view, as a guiding process. When a model loses its utility it should be discarded.

The infrastructure layer appears to hold the least interest for digital humanists, dealing as it does with the plumbing of the web, but it should not remain as neglected as it has been. Viewed from one perspective (the one typically found in the communications rooms of enterprise-scale IT departments), it isn't Microsoft, Apple or IBM that rule the IT world, after all, but companies like CISCO who provide the routers, switches and network infrastructure. In the future it may well involve companies who offer cloud platforms like Amazon AWS and Rackspace, both of whom are developing services of immense interest to digital humanists: on the one hand it appears it’s becoming possible to outsource the IT department, on the other there are warnings from experts of the pitfalls of cloud services and the need for caution. Who is looking out for and providing advice to digital humanists on these topics?

This opaque world is understood completely by a relatively small number of specialists, but some things are clear enough: it is at this level that real control of the WWW resides, at the level of routing and packet switching. Indeed, this layer is so opaque that its main interest for digital humanists may well be the point where the discipline intersects with philosophy. (As Matthew Kirschenbaum has shown, there are equally beguiling problems to be found at the level of logic gates, hard-drives and the machine code that runs atop them.) The infrastructure layer includes a myriad of hardware and infrastructure: M9000 and P7 servers, blade racks and SATA drives, not to mention supercomputing facilities that measure performance in petaflops. Operating Systems could also be positioned in this layer, but note that these will often be IBM AIX systems, or other Unix-based ones like Ubuntu Linux, BSD, Solaris or Red Hat. They will not be made by Apple and may not necessarily be made by Microsoft. Whether this matters to digital humanists is moot in practical terms because they typically purchase services from either university or commercial providers and only ask that those services remain functional; as a discipline we are as much infrastructure agnostic as infrastructure ignorant. In political terms, though, digital humanists should surely be interested in the development of a safe and competitive ecosystem at this level as much as they are at the application level, with a healthy degree of variety and an emphasis on security. Perhaps of more topical concern at this layer are the questions of data centers and virtualization: on the one hand we have giant data centers being built by the likes of Google and Facebook, who are both amassing an unparalleled degree of control over our personal data, and on the other we have widespread moves towards virtualization which looks likely to take us back to the days of thin clients and mainframes. The world's IT infrastructure is moving full circle back to the days where HAL9000 was conceived: massive, centralized computing centers accessed only by a monitor and keyboard. In our case, instead of time-sharing on a single operating system we may well be served our own copy of Windows, Apple or Ubuntu. The trend seems both economically and environmentally sound, but there is ample fodder for the novelists among us. The days of the Homebrew Computer Club, and the absolute level of control those days offered us, is coming to an end.

In terms of an enterprise model of the digital humanities, the weakest point could well be that of Philosophy. It is because of that that I've bracketed it here with Ideology, because it is my assertion that in the absence of a robust philosophical approach to the digital humanities we will only have ideology, which is not a pleasing prospect in the context of IT. Some of the potential topics for a philosophy of the digital humanities were touched on in my introduction to enterprise architecture and my discussion of the infrastructure layer, but there are many more topics that require investigation. Open Access and academia is one obvious area for further investigation. As I suggested above, I strongly support the open access and open source movements and believe the digital humanities should align to them. I also intuitively believe that the humanist tradition has a natural affinity towards them, but is this the case when it comes to university-based humanists? Academia has long been a bedfellow of the commercial publishing world, and is closely allied to both government and private industry. John Willinsky has given us good reason to accept the alignment between the academy and open access as a natural one, but all of us know academics who would vigorously disagree with him. Open source and open access principles are as likely to be championed and practiced by a computer science student or employee of a commercial IT company as an academic humanist schooled in the philosophies of John Stuart Mill. What does this say about the state of not only the digital humanities, but university-based humanities generally, and how would we gather evidence to test the assertion? Do we need a renewed commitment to open access and open source principles? Are we focusing enough on consciousness raising across the academy? Are universities so dependent on a commercial business model that we can’t go open access without undermining the entire enterprise? Cultural and media studies have a lot to offer here, as do literary critics with a focus on technology and ideas.

Another interesting question is perhaps the history of ideas that binds classical logic with the logic of information systems, and the history of mathematics that details the development of algorithms and the methods used in object oriented programming. The history of technology and the humanities computing tradition have a lot to offer in this layer, putting the discipline into its proper context and reminding us of the engineered nature of not only the hardware, but the software that runs on it. Without this kind of research, digital humanists are apt to forget, or fail to adequately understand, the implications of working with two state machines. The issue runs deeper than the relationship between hardware logic gates and binary code: it bears upon a philosophical domain that sits somewhere between machine-level logic and frontier-issues like cybernetics and artificial intelligence. To locate this domain, we need to imagine a ‘continuum of understanding’ that takes us from two state machines, to the application of discrete mathematics and predicate logic to those machines in order to build creative work environments. This much is clear enough, but our understanding is severed here: as soon as we are presented with our creative environments we ignore the prior continuum and work as though our tool was as natural as parchment and pen. The continuum is then re-entered and we readily move to questions of cybernetics and artificial intelligence, quite forgetting that there is a huge gap in our humanist understanding of computers and the digital world at that earlier and far more fundamental interface between two-state logic and human creativity. Something seems to have been missed here. This is the precise point, after all, at which the (classically derived) logic that powers our machines enables the (classically derived) humanist logic that powers all that we create on them. It is, in sum, the event horizon of the digital humanities.

A capabilities model such as that sketched here represents the “view from 40,000 feet”. By its very nature it is both general and liable to adaption and change. It is also, however, one of the tried and tested means by which large, complex information systems are conceptualized, governed and improved through enterprise architecture. As the digital humanities grow, it is no longer going to be enough to focus on code and content in the 'engine rooms' of the Tools & Applications and Content layers. There will be a need for some people to adopt a high-level overview of the undertaking as a whole so that they can create philosophies, practices and frameworks that will ensure the transparent functioning of the whole. Because as much as humanists may baulk at a view of their world that seems to imply a growing leviathan, it is surely better to learn from the history of systems development and deploy (and adapt) methodologies that will help us understand the boundaries of our subject area, produce maximally efficient designs, and point us towards the more esoteric limits of our discipline.