Three technological forces which are currently impacting organizations are virtualization, cloud computing, and open source. Discuss what they are, their impact on business goals and IT strategy.

In this essay, I discuss three factors in IT that are currently impacting or will soon be impacting business goals and IT strategy: virtualization, cloud computing and open source.

Virtualization

Virtualization is a technology which allows one physical server to run many virtual servers.  By virtual server,  I mean a software container that contains a full operating system and set of software, just like a traditional server would.   Each virtual server “believes” that it is running on physical hardware, and thus any software you would run normally on real physical machines will work without modification in a virtual server.  Furthermore, each virtual server appears to the outside world – to clients which connect to them – to be traditional physical machines with dedicated hardware.     The operating system of the physical server provides hardware interfaces to the virtual servers via simulation in softwre: CPUs, hard drives, network interfaces, displays, CD roms, etc..   The physical server translates I/O to these virtual devices to the I/O to the requisite physical devices, if necessary.  The resources allocated to virtual machines can be changed nearly on-demand (disk, memory, network interfaces); most operating systems need merely to be rebooted in order to see the new resources.   Limiting factors in how many virtual machines an individual virtualization server can run are simply how much memory, disk space and network bandwidth the virtualization server has available to it, and to how many resources each virtual machine consumes.   A very basic virtualization server could host eight to twenty virtualized machines.

Furthermore, most implementations of virtualization technology allow a cluster of physical virtualization servers to seamlessly exchange running virtual machines.

Virtualization is a paradigmatic shift in server resource provisioning for several reasons. First, once an organization has built  a cluster of virtualization servers, new server provisioning can happen without an additional capital outlay, without having to have machines shipped, unpacked, tested, racked and provisioned with networking,  and  with substantially less power consumption.  Thus the barrier to entry for new services and servers, and the time to bring a server up from identification of a need to a working system can be dramatically be reduced.   Operating costs for datacenters also become dramatically reduced.   Secondly, the on-demand provisioning characteristic of virtualization lowers the risk of implementation – if a virtualized server doesn’t work out, we simply delete it.   If we didn’t allocate enough RAM or disk to it, we can add more; or if we started with too much RAM or disk, we can reduce it   There is no sunk cost (aside from staff time), and no depreciating, aging physical hardware to dispose of .    Thirdly, once a cluster of virtualization servers has been built, organizations can experience improved uptime due to being able to move virtual servers from physical server to physical server without impact to the users; this allows us to lower the cost of hardware maintenance and outages.

Among the drawbacks of virtualization are that it can be quite expensive to set up a virtualization cluster.  Virtualization machines should be very powerful, with a large amount of computational resources and RAM.  They should be SAN backed to enable quick recovery from hardware faults and to enable seamless moving of virtual servers.   Managing virtualization servers and virtualized machines requires a new and somewhat different and deeper set of skills than managing individual physical servers, because the environment that virtual servers run in is significantly more complicated, technology-wise, than is that which physical servers run in.  Thus we can have fault conditions and problems that we’ve never experienced before.   Furthermore, not every service can be virtualized:  services which need direct hardware access or very high resource allocation are not good candidates for virtualization.   High performance database servers and graphics render farms are good examples of this.

Cloud computing

Cloud computing is really closely related to virtualization technology these days, because virtualization has really enabled the rapid growth in cloud computing offerings.   Cloud computing is an outsourcing option for many different kinds of technologies: applications, infrastructure, computing, and development platforms.   The term “cloud” is borrowed from its common usage in describing the Internet, and for the same reasons:  clouds appear to the user to be homogenous single point entities, but are complex and may be widely distributed geographically and be heterogeneous behind the scenes.  Cloud computing has several characteristics that it shares with traditional managed computing:

• A client utilizing a cloud computing vendor trades up front capital outlay for hardware and software with a use-based or monthly fee.
• The client provisions, manages, accesses the resources they use in the cloud via the Internet.

Cloud computing has several characteristics which differentiate it from traditional managed hosting outsourcing.

• It is device and location independent: we should be able to use any device (desktop, wireless device) to access our cloud, and should be able to get to it from anywhere in the world
• It allows on-demand resource provision, much like virtualization does. We can add, change or remove resources as needed and on the fly.
• In some cases (cloud storage, cloud compute clusters), it offers utility computing: per byte or timespan fees instead of monthly.
• It has a flat performance characteristic – we can expect it to generally behave the same over time.
• Resources in the cloud are geographically distributed, and thus we should see increased reliability over managed hosting.

Many different kinds of resources are currently being offered as clouds:  server provisioning (www.slicehost.com), applications (Google Apps), compute clustering/scientific computing (Amazon’s EC2), storage (Amazon’s S3), web platforms (Ruby on Rails, Python Django, Java, and PHP web development frameworks are all available as clouds from various vendors).   Virtualization on the vendor end is a major technology in providing cloud computing offerings.

In terms of using clouds to deploy services, everything that I said about the benefits of virtualization to the organization are true for cloud computing as well: lower barrier to entry for new services, lowers risk of implementation, lower operating costs.   Additionally, the organization forgoes the capital outlay an operating costs for the virtualization cluster and staff skillsets to run it.   Clouds offer other advantages since one can get infrastructure (storage and database) and application (e-mail, document suites) and intermittent use computing (Amazon EC2 on-the-fly scientific parallel computing). The usual caveats regarding outsourcing apply: you probably shouldn’t outsource a core competency/service; carefully select your vendor (finances, past performance); be careful in writing your SLA; understand that it can be difficult to bring services back inside once you’ve outsourced them.  Although clouds should provide better service reliability than can be provided internally by most firms, nearly every major cloud vendor has had significant service outages.

Open source

Open source software is user designed, implemented and maintained software whose intellectual property (code) is released into the commons and distributed via the Internet for all to use and benefit from.   Open source software projects typically do not have a vendor that supports them.   Instead they are designed, implemented and maintained by a self-organizing group of volunteer, uncompensated, independent developers and users, and are typically started by one or a handful of developers to solve a personal need.   Support comes from volunteers from the community surrounding the software.  A firm does not buy open source software.

The philosophy of open source development is embodied by a saying of Linus Torvalds, creator and maintainer of the Linux kernel: “with enough eyes, all bugs are shallow.”   The quality of much successfully open source software (the Apache webserver, the Firefox and Mozilla browsers, the Wordpress blogging platform, and the postfix and sendmail SMTP servers are only a handful of the many success stories) shows at least that Torvalds is on to something.  Open source software differs substantially from commercial software, where a firm creates software to fill a perceived need of their market, and then sells rights to use the software they’ve created while retaining intellectual property rights.

The decision of a firm to use open source software is an outsourcing decision, much as purchasing and developing commercial software is, and as such, but open source software and commercial software incur the same kinds of  considerations that any outsourcing arrangement might have, plus many other common considerations: integration and customization costs, for example.  I will therefore consider the impact of open source software on firm and IT strategy as it contrasts with commercial software.     The main differences are in cost savings, support (troubleshooting, documentation, bug fixes and feature requests), in project lifecycle, community dynamics, design and focus, project types, and legal issues.

Open source software is free to use, and this is very attractive to firms, because the budget that would be tied up in software licensing fees can be used for other purposes.  On the other hand when a firm uses open source software they don’t have a contractual arrangement with the developers.  Open source development communities are not beholden to firms who use their products to fulfill the firm’s needs.  There are many implications of this lack of a formal relationship.  Open source software is supported by volunteers (although there are also some companies that offer support for open source software packages as a value added service), and as such it can sometimes be difficult to find sufficient documentation and training (coding is far sexier than writing documentation).  Further, if you submit a development request – bug or feature – it may or may not be fulfilled.    On the other hand, if the firm’s IT staff is skilled the fact that the code for open source projects is freely available enables the staff to make their own bug fixes and enhancements, as well as provide examples to learn from.   Open source projects may die due to lack of interest, may “fork” (split into two projects).

Open source development communities tend to focus on certain genres of software: internet services (www, ftp, blogging, etc.), operating systems (Linux, *BSD), systems support, development support (eclipse), some desktop applications (OpenOffice, gimp).  Large software (data warehousing and OLAP, ERP, CRM and SCM tools) have not been worked on yet, and as such the impact of open source software on the firm will be in  subset of all the areas of IT that a firm might have interest in.

There are also legal issues that come with open source, especially for software developers.  Much open source software is distributed with software licenses (the GPL for example) that prohibit it from being used in other products without causing the intellectual property of those products to be also released to the commons.   Although this has not been challenged in court (to my knowledge), software development firms who wish to profit off of software they’ve built that incorporates open source code should be careful, as this incurs potential risk.

Describe action science: what is it, how do you do it, what is good action science, and how do you evaluate it relative to other traditions.  Compare to social science research.

In this essay, I describe action science.  I talk about what it is, and describe some methodology for how you do it.   I describe some characteristics of good action science research, and compare it to design, fixed and flexible research.

Action research was first used in the mid 1940s, but did see much adoption in social science until the last few decades.   In that time it has become increasingly well adopted in education research has become a very viable option for organization science and IS researchers. Action research and its variant participatory action research are research methodologies that do what Robson calls “emancipatory science.”   The fundamental tenet of action research is that we learn about how a social process or system a system works by purposely introducing a change to that system and seeing what happens.

The foundation of action research is the understanding that human social systems are complex and that they cannot be understood by breaking them down into component pieces.  They must be examined in whole in the context in which they live.   Further, humans are not experimental subjects: they are independent beings with free will who should be treated as the equal to the researcher in the research process.  Thus we research them by bringing the researcher to the context under study, and include the people who are part of the process or system under study directly in the research process.   In traditional action research, the researcher still holds a privileged position in the research process in that they can be said to be the one doing the majority of the research work, while in participatory action research, the researcher empowers the participants in the study with the tools to carry out research on their own.

Action research has several necessary characteristics: the researcher studies a problem of direct interest to the social process or system in question which will produce findings that can be immediately applied back both to the context and to the field; the study will be firmly grounded in theory, linking theory to practice; and the research will use qualitative and flexible data collection and analysis methods.    The firm foundation of action science in theory and its emphasis on making scientific as well as pragmatic contributions is what distinguishes action science from consulting.    Action science data analysis is interpretive in that the researcher invariably becomes part of the process or context and thus there is an unavoidable viewpoint in some of the data collection and analysis of researcher-as-subject.  It is idiographic in that since the work is done within a particular context, it necessarily must be interpreted in light of symbols, ideas, conventions and meanings from that context.

Action research is a cyclical process, and each cycle of the process has some well defined phases:

1. Identify and characterize the problem to be studied and addressed
2. Identify relevant theory that can help in understanding the problem and in identifying an action to take in perturbing the social process or system.
3. Evaluate the current situation: what is happening now?
4. Define an action to perform which perturbs the social process or system
5. Evaluate the effects of the action on the social process or system, if there are any effects.
6. Use those results to decide what to do next.  This can be any or all of: identify another problem to be studied and addressed, choose different theories, choose different action.   This part necessarily involves self-reflection on the part of the participants
7. Repeat the cycle.

In traditional action research, the researcher is performing most of these steps, while in participatory action research, the researcher acts more as a mentor and source of knowledge of social science theory to the participant-researchers, teaching them how to do the research themselves and having them do it: identify the problem, evaluate the current situation, choose action, perform action, evaluate results, repeat.   In this way, in some cases, action research performed in a context may be self sustaining

Action research can be a frustrating process for many reasons, and researchers should plan accordingly.   It takes time to introduce meaningful change to a social system (Robson says “allow at least two years”).  Planned actions may have no effect or have a different or opposite effect than that intended.  People in the social context may be very resistant to the idea of change.   There is always a political dimension to action research, which at least involves changing how a social system works, and may involve teaching participants how to carry on the process of change on their own.   In some cases, the research will be done with the support of the parent government or organization, and in some the researcher will have no such support or may be inhibited from performing the work.

From the point of view of the researcher, action research can be very rewarding since through it the researcher can effect real change to real social systems, but it can also be frustrating career wise.  Since in action research it is difficult to predict from the start where the research may ultimately end up (due to the iterative nature), it is difficult to found a cohesive theme for one’s research.   There is also a lack of agreed upon criteria among editors and researchers for evaluating action research, and since action research papers tend to run longer than fixed, flexible and design research papers (because of the iterative nature), it may be difficult to find a journal to accept such papers.

As compared with design research, action research differs in the focus of the research.  Design research is artifact focused: identify a problem and design an artifact to solve the problem, then evaluate how well the artifact does so.  The focus of action research is the system and the changes introduced.    We may introduce an IT artifact as the change to perturb the system, but it is ultimately the system that we are interested in.

As compared with fixed research, action research differs in many fundamental ways.  Action research, like many forms of flexible research, looks at a human system from the inside (intepretivist and idiographic) treating people in the system as collaborators or co-researchers.  Fixed research looks at it (or tries to do so) from the outside, as the researcher performing experiments upon subjects.   There is also less or no emphasis in fixed research in returning useful, applicable findings back to the people in the research context as there is in action research.    The data collection and analysis techniques between fixed and action research are of course different: quantitative and determined in advance for fixed; qualitative and adjusted on the fly for action research.

As compared with flexible research, action research and flexible research are similar in technique, but differ in stance.   Action research borrows many techniques from flexible research types (especially case studies, grounded research and ethnographies).   But where in flexible research the researcher takes a passive stance, observing and reporting the system or process and trying to not influence it, in action research the researcher of course necessarily takes an active stance and purposely changes the system and becomes therefore a participant in it.  The idea of the researcher “going native” is frowned upon as a source of validity concerns in flexible research, but happens as a matter of course in action research.

Discuss outsourcing as an option for IT org in satisfying the needs of the business.  What are the: range of available options?  When is outsourcing a viable option? When is it not indicated?  What is current thinking on outsourcing?  What about offshoring?

In this essay, I discuss outsourcing and offshoring as options for the enterprise.  I discuss available options and considerations and discuss a framework for deciding when and what to outsource.   I then finish with current thinking among CIOs regarding outsourcing.

Outsourcing in an IT context is contracting with a third party to provide the enterprise with an IT related function.  This can be from as simple from hosting a website to as complicated as taking on the entire IT function for the firm.  There are two classes of outsourcing: networked incremental outsourcing and full scale outsourcing.   Firms choose to outsource for a combination of primarily three options: cost and cost structure (being able to trade a intermittent fixed cost for a periodic variable cost), quality and capability of the in-house IT organization, and whether the IT function to be outsourced is a core competency for the enterprise.

In networked incremental outsourcing, the enterprise wants to outsource a single service from a suite of similar services to an outsourcer.  Internet hosting are the paradigmatic example of incremental outsourcers.  They offer anything from managed web software services (Wordpress hosting companies, for example)  to shared servers (in which you are given a slice of a server on which you can manage the website configuration and data, but they maintain the machine, operating system and database server) to co-location (in which you are given physical space, power, network connectivity and possibly other support services, but you supply and maintain the hardware and software you need).   These are called incremental outsourcing arrangements because a firm can either start at the low end (the cheap end) and trade up, or start at the high end (the resource expensive end) and trade down should their confidence in the company increase.  Incremental outsourcing allows a company fine grained control over what IT functions on what services to keep in-house, and what to outsource.  Characteristics of enterprise architecture and financial arrangement in a company which are conducive to incremental outsourcing are: the internal costing structures are prepared for the periodic small variable cost of many services; and the IT architecture and skillset of the IT organization can effectively integrate the outsourced service.   Drivers for this kind of outsourcing are: a shortage of IT staff resources because they’re too busy doing other things or don’t’ have the requisite skills; decreased time to market because the outsourcer already has the infrastructure and servers built and provisioned; the need to support 24×7 operations when your IT org can’t supply it; outsourcing has a more favorable cash profile because you don’t need to make an initial capital outlay to buy servers; you can decrease desktop complexity because you push applications onto the server and maintain one copy instead of many.

Full scale outsourcing concerns outsourcing large parts of the IT function, or all of it.   Candidates are infrastructure (desktop, network, and server provisioning and maintenance; call center support), development (new product development, product and service innovation, enterprise software development and integration), business process transformation (business/IT alignment consulting and project management), and everything.  Drivers in this domain fall into three categories: issues around the IT organization; issues in the business organization; and market pressures.   Business leaders my opt for large scale IT outsourcing because vendors have better economies of scale than the in-house IT organization, or because the IT organization lacks skills, or is historically reticent to align with business.   The business itself may not see IT as a core competency and may want to outsource it to reduce management oversight to only those functions that are central to the business model.  Or they may opt to take advantage of the financial characteristics of outsourcing, trading periodic capital investment and expensive staff for periodic variable costs, which helps their bottom line.   Business leaders may also feel pressure form competitors who are already outsourcing their IT function, or from aggressive outsourcing vendors.

In determining whether to outsource an IT function or not, a firm should carefully consider whether that function is core to the business model of the firm.  In most cases, outsourcing core competencies is not indicated.  The firm should also think carefully before outsourcing IT management and governance, IT architecture management and vendor management functions.   If we look at the strategic grid model, in which one axis is importance of IT operations to the business model and the other is the importance of strategic use of IT to the model, businesses who are good candidates for large scale IT outsourcing are high operations/low strategy (in which case we outsource the IT strategy functions) and low operations/high strategy (in which case we outsource the operations functions).    In outsourcing projects, well understood, straightforward projects are good candidates, while open ended projects in which the requirements are poorly understood or which require research to complete are not as good of a candidate for outsourcing.  Cost alone is rarely a good indicator of when one should outsource, especially if the desire for cost reduction is short term.     The enterprise should also consider that functions, once outsourced, are very difficult to bring back into the firm due to lost organizational knowledge and capacity, and also that the cost of duplicating function and moving data may be high.

Large scale outsourcing frequently involves long term contracts (ten years) and involves a substantial commitment on both sides: be sure that the outsourcer is both willing (in terms of aligned interests and corporate culture) and able (financially, technically) to fulfill its obligations.  Contract negotiation can take six to nine months for such deals, and it is important to consider in the negotiation how the relationship is going to be maintained over the years.  The IT org must be capable of managing relationships with the vendor for the long term; they should maintain tight relationships with them, because in these long term contracts the outsourcer becomes almost a partner to the company.   Relationship management is a skill that that is not intrinsic, and must be learned by the IT org.

Offshoring is outsourcing to vendors which are overseas, typically in India and China where the costs of personnel are lower than in Western countries.   Things to consider when thinking of offshoring are the dramatic cultural (both organizational and national) and language differences between client and vendor, the communication cost of communicating half way around the world and not being able to meet face to face, and the time differences.

In today’s recession, firms are opting for smaller and shorter contracts with vendors, and are staying away from open ended contracts (innovation and business process transformation).  Firms should think carefully about obtaining or renewing outsourcing agreements for several reasons.  First, be sure that you’re not doing it for short term cost reasons only, because once the economy improves you’ll still be saddled with the contract even if you’re ready to move on.   Learn from the mistakes of the great outsourcing push of the late 1990s.  Second, since many firms will rush to do outsourcing, we can expect vendors service levels to drop (because they’re taking more customers) while simultaneously, the balance of power between clients and vendors shifts in the vendors’ favor (again, because they have many customers).  Third, the recession affects outsourcers just as much as it affects everyone else, and we can expect some vendors to fail.  Firms should monitor the health of their vendors carefully, and examine the health of new vendors carefully before signing any contracts.

Data warehousing: what is it, why do we want to do it, how is it done?  How do data warehouses compare with operational databases? What do we want to consider when doing so, and what are our options in terms of implementation?

In this article, I discuss data warehouses: what they are, how they compare to operational databases, and how they are designed, implemented and maintained.

An operational database is one which is used by the enterprise to run its day to day operations.  They are created to support fast transaction processing, with frequent updates.  Speed is key to operational databases.  They typically are used by clerical staff, and are on the order of megabytes of data to gigabytes.  Database consistency is very important to operational databases, and consistency checks and constraints are rigidly enforced.  They contain the most current set of data applicable to running enterprise operations.  These are our sales and inventory databases.

A data warehouse differs from this in many ways.  They are used by management for making decisions, watching trends, and running reports.  They are typically used offline, have few users and are very large: gigabytes to terabytes.  They contain historical data, are read only, and are added to but rarely or never updated (the rows in the database are not changed, I mean).  The data in the data warehouse is time sensitive – each row is the warehouse is timestamped so that trending of data versus time can be done.   The kinds of queries that are run against data warehouses are complex, containing many WHERE, JOIN and UNION clauses.   These are decision support databases that are used to make strategic decisions about the enterprise.

Organizations make data warehouses in order to gain insight into trends, anomalies and exceptions in enterprise data that affect the business strategically.  This kind of analysis and reporting is called OLAP: on line analytical processing.   Management uses OLAP tools on the data warehouse to pull reports and make decisions.   This would not be possible to do with an operational data store, since the operational data store contains data that is only true at the current time.  For instance, an operational database which describes inventory would only describe what is in stock currently, not what was in stock last week.  Data warehouses would contain snapshots of the operational data for many instances of time, and so would show inventory both as of now and as of last week.

At this point, I want to distinguish between two terms: data warehouse and data mart.  A data warehouse is used to store all the data that an enterprise would need to make decisions about any part of itself.  A data mart contains only a part of the data that the organization uses.   Data marts can be either implemented as a subset or building block for a data warehouse, or as an independent entity.

There are two design aspects to consider when we think of data warehousing: how do we get data from the operational databases into the data warehouse, and how do we design the data warehouse itself.

Getting data from the operational database to the data warehouse occurs via a process called ETL: extraction, translation and loading.  Data are extracted periodically from the operational database into a temporary holding area, they are transformed – aggregated, massaged, timestamped, converted from the data definition of the operational database to that of the data warehouse – and then are loaded into the data warehouse.  This loading typically happens daily, and can involve many operational databases.   It is a time consuming operation, and optimizing ETL is an ongoing research topic.

There are two issues to consider when designing data warehouses: enterprise issues and technical issues.   From an enterprise perspective, implementing a data warehouse is an immense project that can take months or years to complete.  There are two models for doing this: the Bruce Kimball bottom-up method and the Bill Inmann top-down method.  In the bottom-up method, the organization starts by identifying a business need for trending or reporting and builds a data mart to satisfy that one need.  This can be accomplished quickly. Over time, more data marts are created and more complicated questions can begin to be asked which span data marts.  Eventually all the relevant enterprise data is implemented as data marts within the data warehouse.  The thing that makes this work is that there must be an organizational standards body that defines and enforces a common data model as data marts are created and integrated.  What I mean by this is that different operational databases may use different data definitions of the same kind of object: a person for example.   The role of the standards body is to define a common person data definition, and cause (during ETL) data from the various operational databases to be transformed from their native definition to the common one. This is important because it makes reporting far simpler and prevents data duplication throughout the warehouse.

In the top-down method, we identify all the core data we need from the organization first (without identifying relevant business purposes for that data yet) and implement that as a bottom layer of normalized tables.  We then build data marts on top of that layer.   In the bottom-up approach, we define the common data definition with an iterative approach, while in the top-down approach we define the common data definition all at once before we start.  The first method may cause us to have to rework the warehouse as we go along, while the latter incurs substantial startup cost.

When writing of technical considerations when designing data warehouses, I mean two things: logical design, and physical design.   Data warehouses can huge huge amounts of data, and queries on that data can be complex, with complicated WHERE clauses, many JOINs, UNIONs, and aggregations and computations involved.  The challenge in data warehousing is in designing the database such that such queries will finish in a reasonable amount of time.  Ideally, this is less than 10-15 seconds when doing interactive OLAP queries (the time it takes for someone to lose their concentration and flow), longer for canned reports (minutes, though, not hours).   At the logical level, the industry is split into two camps: star schemas and snowflake schemas.  In both designs, we organize a set of tables around a central table, called the fact table.  The fact table contains the things we want to run queries on, and the surrounding tables (called dimensions), bound to the fact table through foreign key constraints, contain data which describes the rows in the fact table.   In the star schema design, the dimension tables are denormalized to reduce the number of JOINs necessary in queries on the fact table, while in the snowflake schema the dimension tables are normalized to reduce data duplication and allow reuse of those tables with other fact tables.

At a physical level, data warehouses tend to be heavily indexed and partitioned to put the most used data on faster storage.   There are other options available as well.  Multi-dimensional databases attempt to speed queries which must aggregate or derive data in the fact table by storing pre-calculated aggregate shadow tables in the database which the query optimizer will use when appropriate.  For instance, a common set of aggregates are per-time aggregates, pre-calculating per day, per week, per month, per quarter and per year sums of a fact table.   One can implement this within a relational database, in which case it is called a ROLAP database.  There are also special products which implement more effectively these multi-dimensional functionalities by storing data in non-relational form: these are called MOLAP databases.

When we talk about the value of IT as being that of providing value now and opening new options for value in the future, data warehousing is a perfect example of that, and it is clear from the press and research around data warehousing that both the business and research communities understand this.   Data warehouses are typically designed with specific questions in mind, but as data grows, the warehouse gains value because there are new questions that can be asked if only the enterprise is perceptive enough to see them.  Those questions and their answers can lead to new opportunities for creating competitive advantage.  Amazon is a perfect example of this: they have gathered over the last decade a tremendous amounts of data on buying habits of their customers, the trustworthiness of different used book vendors and the popularity of various books and items, and have continually leveraged that data to emphasize their brand (raising barriers to entry in their market), increase switching costs for their users (because having books recommended to you is helpful, but you have to work to let Amazon know what you like by) thus reducing the threat of substitution.

There is a large amount of research into data warehousing in the database community on several fronts: data mining (how do we use our data warehouse effectively), recommender systems (really big now), data warehouse design and construction (such as what Kimball and Inmann do), query optimization, multi-dimensional databases and their implementation.

Nicolas Carr’s book “Does IT Matter” generated much debate about the value of IT to the firm, primarily in terms of conferring competitive advantage.  Summarize his argument, and (if appropriate) refute it.  In your opinion, what is the value of IT to the firm?

Nicolas Carr’s book Does IT Matter was about the value of IT to the firm: does it confer competitive advantage to the firm, and if so, how?   In this essay, I discuss how IT can create value for organizations.  I then summarize Carr’s argument, and offer rebuttals to it.

What is the value of  IT?   It gives value to the organization in that it can processes information into forms more suitable to the purposes of the firm, it can deliver that information to the people who need to see it when they need to see it, and in that it can enhance the ability of people in the firm to communicate and collaborate.  All of this can be used to either add value to the firm by opening opportunities or reduce costs of operation and development.   IT can affect the firm’s business model in one of five ways.  It can reduce the power that a firm’s suppliers and customers have over the firm.   It can affect barriers to entry in markets, either lowering them in markets the firm wants to enter, or raising them in markets in which the firm is well established.   It can raise or lower product/service switching costs: Gmail has it’s customer’s e-mail and the more they have, the harder it is for a customer to switch to another e-mail provider; conversely the Internet lowers switching costs for services who don’t keep data like Gmail does, because everything is equally far away on the Internet.  It can change the nature of competition between a firm and its rivals by offering new information to customers and staff, and by transforming business processes and value chains.   It can enhance existing products and services that the firm offers, or allow it to offer new products and services.   As we’ve seen when businesses took to the Internet, and as they are now taking to mobile phones, it can open new channels to existing markets or open new markets.

Carr’s argument is that IT is no longer strategically important to firms because it can no longer confer competitive advantage to them, which means that they can no longer rely on only IT to help them to do better than their rivals in the markets in which they operate.   His argument has two parts.  First, that IT, especially IT infrastructure, has become so cheap, powerful and easily available to all that it has become commoditized, like electrical power or the telephone service.   Second, he says that IT is now easily replicable, so that even if a firm would think of a novel way to use IT, it would be copied quickly by their rivals and their competitive advantage would disappear.

His first claim he supports by saying that Moore’s law (computers become twice as powerful for the same or lesser price every 18 months) and Gilder’s law (network bandwidth doubles every 6 months) have driven the price of  powerful computing hardware and networking equipment down to the point where any firm can afford them.  Gone are the days when simply owning a computer or having a WAN could give you an edge over your rivals that could last years.   He says that commercial off the shelf software (COTS) has become so powerful and complex, embodying industry wide best-practices, that it would not make financial sense for a firm to attempt to duplicate them.  He’s thinking of ERP, CRM and SCM software here, I imagine, as well as office software like word processors.   Finally, he says that  the dominance of standards in IT (the Internet, the WWW, Web Services, etc.) is such that shared infrastructure gives more value to the firm in terms of cost savings than the firm would get from developing a non-standards compliant IT artifact (that a competitor would have to duplicate, presumably).

Carr’s second claim – easy replicability of IT solutions – he supports as follows.  Programmers are cheap, programming tools are very powerful, and software is easy and cheap to write.   Hardware and software are, these days, plug and play building blocks, and hardware is pretty homogenous.

Carr has two fundamental misunderstandings regarding IT.  First, that IT is a drop in solution for any organization, like adding new electrical capacity to the factory floor in a manufacturing plant.  It is not.  Second, that IT infrastructure is single use, again, like the electrical grid which provides power to firms and nothing else.

As we know well, being IS researchers, the IT artifact is surrounded by business processes which must be changed or created to integrate the IT artifact effectively into the business,  It is used by humans who have more or less willingness and ability to use the artifact.  And it is embedded in an organizational context: a business which has an organizational culture which can be hostile to the IT artifact, an enterprise architecture into which the artifact must fit,  an absorptive capacity (the ability of the organization to understand how to learn to use the artifact effectively).  All of this affects the ability of the firm to use the IT artifact effectively.   Business/IT alignment is goes both ways: we must adapt the new IT artifact to the business environment, and we must adapt the business environment to the IT artifact.   This adaptation takes time, years possibly, especially for the large systems like ERP, CRM and SCM systems.   So even though the much knowledge, learning and complexity is embedded in these COTS systems, that is only part of the battle.  In fact, it is debatable for some kinds of systems whether (if the firm has R&D capacity) it is more expensive to adapt the system to organization and vice versa, or write the system from the ground up to mate well with the organization.  Content management systems are good examples of this.  Thus, even if the IT artifact itself is a commodity, it can still confer competitive advantage to the firm due to process, people, and organizational context issues.

Carr’s second misunderstanding is about single-use IT.  IT typically offers not just a single unchangeable use.  Think of the Internet, which has been in operation since the late 1960s and whose core protocols have hardly changed since the 1970s.  Every year (every few weeks or days, probably), people think of new ways to leverage the same infrastructure, ways that could not have been predicted back in the 1960s.  This is the value of infrastructure, properly designed: it creates value by creating options.   An IT artifact typically confers a short term value that is easy to replicate – this is the goal for which the artifact was designed.  But if it is designed properly, the artifact offers value in the long term because it can be used for goals which were not foreseen during its design.  This is especially true of infrastructural components of an artifact.   It is this future opportunities that can confer competitive advantage, because it takes talent, vision and effective Business and IT governance to see and take advantage of them.   Not every firm has this.

What is theory, how do we test theory, how do we prove (tentatively) that a theory is true, what are the different kinds of theory; compare and contrast the various styles of theories.

In this essay, I describe what we mean when we talk about scientific theories, I discuss how theories are made, and how they are tested, and what we mean when we say a theory is “true.”  I describe a taxonomy of theories types, and give advantages and disadvantages of the different types.

A theory is a claim on the natural world which is supported by observational evidence.   Scientific theories are testable statements, testable through observation and interaction with the world we all share.    The National Academy of Sciences goes somewhat further and says that a theory is a claim about the world supported by observational evidence which is unlikely to be disproved by further evidence, and they give the theory of biological evolution and the germ theory of disease as examples.   Theories make up the scientific body of knowledge, and serve one of four roles: they allow us to classify things in the world; they describe part of the world and allow us to make predictions about that part (correlation); they provide a sense of understanding about the world (causation); and possibly they allow us to control that part of the world (use our sense of understanding to change the world in a predictable way).  Good theories are tentative, malleable and available to be falsified, and are parsimonious: given options to choose among several theories that explain the same observational evidence, we should prefer theories that describe the world in the simplest way (Occam’s razor).  They are abstract (not tied to a particular time or place) and intersubjective (all scientists in a field agree on what they mean).

Reynolds describes three forms of theory: set of laws, axiomatic, and causal process.   A law is a correlative relational statement between two variables in the world that is well supported by observational evidence to the point where it is accepted as “true” by the relevant field.  A set of laws theory describes an area of the world via a set of independent laws.   Set of laws theories can be used to explain and predict things (show correlation) but not give a sense of understanding (show causation) or control.  The main problems with set of laws theories are that they can’t describe unobservable features of the world, and they suffer from a massive combinatorics problem when having to describe interrelationships among many variables.   An axiomatic theory  proposes a set of interrelated statements (axioms) which can be combined in prescribed ways (typically mathematical or logical) to generate other, derived statements called propositions.  Support for any proposition or axiom gives support to the theory as a whole.   The good thing about axiomatic vs set of laws is that we have to do less work to show improve support for the theory, and axiomatic theories can encompass unobservables.  Axiomatic theories can be used to explain and predict, and possibly to give a sense of understanding and offer control, but the latter two are not necessary for axiomatic theories.   Causal process theories are like axiomatic theories in that they consist of a set of interrelated statements, but they differ in that causal process theories must relate cause and effect in the observed variables and thus implicitly offer a sense of understanding and possibly control.   Causal process theories have all the advantages of axiomatic theories, with the benefit of conferring a sense of understanding.  A problem with causal process theories, especially in complex systems, is to know when you are “done” adding bits to your model of the process.

“Truth” in science is not the same as truth in philosophy or mathematics in that science is inherently fallabilistic.    Fallabilism in science says that we understand that our current theories of the world only approximate what is really happening in the world, and that they can be wrong.  We expect both to make new theories in the future which explain parts of the world as yet unexplained, and to improve existing theories to better explain the parts we think we have explained.     Truth, in science, has to do with the interaction between empiricism (theories are claims about the world supported by observational evidence), intersubjectivity,  organized skepticism in the scientific community (we do not trust things implicitly; rigorous testing of ideas is necessary before acceptance) and consensus (many scientists in a field accept that a theory does actually  reflect what is happening in the world). There is also a disagreement in what scientists think science can show as true.  The hard core empiricists believe that the best we can do is to show correlation (A happens when B happens), and that causation is not the goal of science.  There are problems with this stance when we try to use scientific knowledge in arguments in which we want to make predictions, because without causation we can make odd statements which would appear to be acceptable, such as “the height of a person is determined by the length of their shadow.”    Scientific naturalists believe that the role of science is, in fact, to establish causation, and therefore the best kind of “truth” is the one which most accurately explains why something happens (causation) not simply that something happens (correlation).

I’ve talked about testing theories, but have not explained what that means.  Theories are abstract (not tied to a particular time or place), but the world is concrete (particular time and space) and we need to derive ways to make concrete statements about the world (observational evidence) that we can tie back to our theories.  The linkage that does that is called an operational definition, and it describes the methods and procedures to generate those concrete statements, and are defined in such a way (intersubjectively) that any scientist can use them to generate the same kinds (equivalent) concrete statements.

Theories are claims about the world based on evidence from the world, I have said, but how are they created?  Several methods have been proposed, and are accepted in varying degrees by scientists and philosophers of sciences.  The Baconian method (research-then-theory) says that we observe the world, look for recurrent patterns in it, and turn those patterns into theories.   There are problems with this approach:  complex systems with many independent and dependent variables may require huge amounts of observations over great periods of time, and even so some aspects of those systems may not be discernable to us, because we don’t know what to look at in all the data.   Reynolds and Robson  propose a composite, iterative approach to theory building.   This involves starting by observing and describing a new area of interest in the world, noting interesting features, composing a theory (not necessarily a set of laws) that explains those features that conforms to the qualities of good theories I discussed above, and then testing our theory back against the world.   After initially investigating our area, we may start by proposing hypotheses about the area (testable statements that have not been shown to be “true” or false), generating operational definitions and testing the hypotheses repeatedly.  If  our hypotheses are continuously supported by observational, we can begin to have confidence that they may be “true” in a scientific sense (inductive reasoning), and we call them empirical generalizations.   If enough people believe our results (intersubjectvity and organized skepticism), our hypthotheses may be accepted as a good theory.

Wide area networks (WANs) are a vital part of many enterprises. Discuss common WAN solutions, and enterprise concerns

In this essay, I will define WANs, describe why they are important to enterprises, discuss common solutions and detail some aspects of WAN design that enterprises will want to be aware of.

WANs are the long haul component of a corporate/organizational network that connect LANs at several different sites.  WANs are what allow organizations to be geographically distributed while still being able to exchange data (voice, data, image, video) easily among their disparate sites.  Also, WANs can allow multiple organizations to internetwork.

There are a number of options available to organizations when considering WAN implementation.  They can be classified as public options, private options, circuit switched, packet switched and direct.   What we are talking about here are last mile options for the sites, not necessarily intermediate network options.  By “intermediate network options,”  I mean how the carrier may choose to deal with the organization’s data after they accept it via whatever connection scheme they have in place for the organization.

Most simply, an organization may buy a leased line to connect two sites.  Although it may be implemented in a public or private circuit switched network, this is a non-switched connection.  The problems with leased lines become apparent when we have many sites to connect – we need a line between any two sites in the set, and the number of lines increases dramatically with each additional site.

Next, an organization can opt to connect to a private switched network – either a circuit or packet switched one.    The org either builds one itself via constructing its own switching nodes and connecting them via leased lines, or contracts with a third party who has such a network and connects to it via leased line.

There are also public circuit and packet switched networks.    The public telephone system is one such example of a public circuit switched network, while telco providers may offer packet switched networks (such as X.25, ATM and frame relay) networking to the organization’s doorstep.

Alternatively, an organization can connect to the most famous public packet switched network: the Internet.   They may do this via a mechanism as simple as via using a modem to connect over the public circuit switched network to their internet service provider (ISP), to leasing a line to their provider, to leasing a line to an internet exchange point (IXP), a single site (typically a single building or a few sites in a building) to which many organizations connect via leased line and in which two stub networks connect to each other directly, or connect to larger transit networks.   A transit network is one which connects to many other networks, and thus an organization’s traffic will transit that network on its way to its destination.  A stub network is the opposite of a transit network – it’s an end point for data.

The factors that organizations should consider when deciding upon WAN options concern the characteristics of an organization’s data, data security and control of network design, availability, and day-to-day operations.   If the organization’s data is bursty, it would be better off with a packet switched network than a circuit switched network.   Control of network design, availability and day-to-day operations all have to do with a compromise between the cost of running, provisioning, and troubleshooting one’s own network with and hiring one’s own staff vs. the lack of control over performance characteristics, downtime and troubleshooting and fixing issues that comes with contracting with a third party for networking services.   In terms of security, this is another “lack of control” issue, but also has to do with the increased vulnerability of placing organizational data onto a public network vs. using a private one.

All the considerations that come with forging outsourcing agreements apply to forming agreements with WAN providers: one should look at financial stability, past performance with other customers, availability statistics, facilities, etc..   One should build contracts that include performance and availability requirements and provider penalties for failing to meet them.   The relationship with the WAN provider should be maintained carefully and continuously.

In this essay, I describe science and scientific knowledge, discuss how that knowledge changes through time, and discuss the social qualities of the scientific community that differentiate it from other communities.

Science, according to Godfrey-Smith in his book Theory and Reality, has three characteristics: it is based in empiricism, meaning that scientific knowledge is relatable through observation to things in the world, it uses mathematics as a way to formally relate concepts, and it has a unique social structure which makes it effective at discovering knowledge about the world.

Scientific knowledge can be used for one of several purposes.  It can be used to classify things in the world (phenomena, objects, characteristics).  This is the “what” of science – what is it and how do we differentiate if from other things.   Scientific knowledge can be used for explanation and prediction, to explain what happened and possibly to be able to predict events.  This is the “how” of scientific knowledge.  It can be used to gain a sense of understanding, which is an extension of explanation:  this tells us why something happened, not just how it happened.  Finally it can be used for control: if we understand why something happened, we can possibly use that knowledge to manipulate the world to cause that something to happen.  This control is not possible for all systems we might have a sense of understanding for.

There are two views of how scientific knowledge changes through time: the one process view and the two process view.   Both views are based in the idea of scientific fallabilism: the scientific body of knowledge at any given point in time approximates reality to the best of human ability at the time.  It does not reflect reality perfectly, and we expect that, as time passes, some of all of that body of knowledge will be replaced with theories that more accurately describe the world.    Scientific change has two parts: covering more of the world and explaining what we think we’ve already covered more accurately.

The one-process view, akin to Argyris’ single loop learning, says that science is evolutionary.  The process of science, the way we generate new theories and test them is constant, but the body of knowledge improves gradually over time.  Popper’s philosophy of science is a good example of one-process science.   He was a a reductionist (the opposite of a holist) and so saw science as a set of  independent theories largely in the form of a set of laws.   He believed that, over time, we gradually add laws to explain more of science and refine existing laws to explain it better.   This is like a traditional gradual Darwinian evolution.

Quine with his holistic theory of knowledge, threw strong doubt onto Popper’s view of scientific change.  Quine holism is a philosophy of science in which one cannot test just one theory (the theory in question) in isolation, but one must inevitably test a whole host of theories.  There are theories that we use in making measurements (the iron in our steel ruler will expand a certain amount at a certain temperature, and our steel ruler is, in fact steel), and our tools were built based on other theories (the microscope really is showing us accurately things that we can’t see with our eyes directly).

In the two-process view of science, not only does the scientific body of knowledge change, but the ways of doing science (methodology) and of expressing and evaluating scientific knowledge may change.  Again, this is akin to Argyris double-loop learning.  Kuhnian revolutions are  exemplar of  two-process idea of science.  Kuhn, late in the 1960s, had a different view of how scientific knowledge changes, a much more dramatic view.   Science within a particular field operates in one of three modes.    In normal mode science, the field operates under a prevailing set of theories, which Kuhn called a paradigm.  A paradigm is not necessarily only set-of-laws, as Popper believed.  The paradgim explains most of the world that the field is interested in, and scientists do not question the foundation theories of the paradigm, but do detail work – looking at how the theory applies to specific contexts, or filling in more detail to the theory.    As this mode progresses, anomalies may build up – observations from the world that the prevailing set of theories cannot sufficiently explain.  When enough anomalies build up, it becomes clear to the field that the prevailing paradigm is not correct or sufficient, and the field descends into chaos.   The large, overarching questions that the formerly prevalent theory explained are now in question, and scientists propose and test new theories which will explain the anomalies.  When a candidate theory is accepted by most scientists, the field goes into revolution, and works to reorient itself under the new theory.  From then on, until the next revolution, it’s normal science.    This revolution (called a Kuhnian revolution) will involve new ways of looking at the world, new methodologies for investigating it, possibly new ways of establishing truth and doing argumentation.   It may be so different, said Kuhn, that ideas from the old paradigm may not be directly comparable to those from the new (Kuhnian incommensurability).

Others build on Kuhnian paradigms to model something closer to how science actually works.  Kuhn said that a field had only one paradigm at a time.  Lakatos said (reflecting reality more) that there is typically more than one competing paradigm in a field at a time, and that the paradigm can be broken into two parts: the hard core of theory that is not questioned, and a soft edge of theory that is questioned and replaced periodically.  Lakatos called this a research tradition.  Laudan expanded on this to say that even the hard core of the paradigm is malleable and can have bits of it be replaced without the need for a Kuhnian revolution.  Laudan called this a research program.

Which brings us to the social mechanism of science.  What makes science work?  Merton was the first to look into the sociology of science, and said that it is comprised of four key characteristics. First it is communal: scientific knowledge is placed into the commons.  It is universal: there are no restrictions on who can become a scientist.  It is disinterested: scientists work for the good of the scientific community, not for their own personal gain.  Finally, it has organized skepticism: the community does not accept new ideas at face value, but instead demands testing and verification.   Individual scientists are motivated by increasing their reputation within the community.  Hull expanded upon this and said that it is not so much reputation that drives scientists, but use of their work – they want other scientists to build upon what they have done.     This usage motivation has tied to it a replicability/skepticism operation; scientists are who use another’s work are motivated to  be skeptical about it and to do their best to ensure that it is accurate, because if they are going to tie their work to it, and it turns out to be false, their work is impacted and then nobody will use their work.   Kirchner addressed the issue of distribution of labor: how does a scientist choose which research program to join?  Answer: join the one that gives the most likelihood of them personally being cited.  This mechanism prevents all scientists in a field from joining one most popular program, because their reputation would be diluted by all the other people in the program.   Thus there is an incentive to try new ideas in order to gain a bigger share of reputation.  Kirchner assumed that everyone’s share of reputation within a program was equal; a later philosopher (whose name escapes me) modified this by saying that the shares are not equal.

To summarize, one can see how ideas about how scientific knowledge changes through time (Kuhn, Lakatos, Laudan; the two process model, research programs) and the sociology of science (Merton and Hull and the operation of science and the motivation of individual scientists; Kirchner and “he who followed” and the division of labor in science) are interrelated.

In this essay, I will describe what design science is, describe necessary components of that make up good design science research, and discuss how to evaluate it.   I’ll then compare design science to behavioral (social science) research.  If the purpose of information systems research is to try understand the issues around information systems in order to enable the application of that knowledge to create technology-based solutions to heretofore unsolved and important business problems (Hevner et.al. 2004), then design science is a research methodology in which the researcher creates an IT artifact in order to both increase our IS understanding and to potentially solve the problem with a working solution instantiated in the appropriate environment.  In creating IT artifacts, design science aims to present a solution and show that the solution works, how well it works, and under what circumstances.  It does not try to show why it works – that is the domain of behavioral science.

A problem can be defined as the difference between a desired end state and the current state of the system (by system, I mean it in the Benbesat and Zmud sense of  a technology used by people via processes embedded in an organizational context and environment).   The problem space, then is the set of all possible ways of approaching that problem and includes both failed and successful solutions.   In design science, the IT artifact something that either helps define the problem space, search it, or is a solution.  It is one of four things: constructs, models, methods and instantiations.   Constructs are the vocabulary and ideas that we can use to describe things in the problem space.  A model uses constructs to describe the problem space.  Methods are procedures and processes which one can use to search the problem space for solutions, and instantiations are technological systems that solve (or try to solve) the problem in question.  A design science research project may define any number of artifacts, but importantly, those artifacts must be implementable in a real environment.

The kind of problems that design science addresses are what Hevner et. al. (2004) call wicked problems: they have many interdependent sub-components, or depend on creativity for a solution, or many people working together (teamwork), or are malleable.

A good design science project has, according to Hevner et. al, seven characteristics.   It produces an artifact, that artifact provides utility in a business sense (possibly meaning that it increases revenue or decreases costs for the target audience if that audience is a for profit business), the researchers formally evaluate the artifact as to its utility in the environment  it is supposed to be helping, that artifact provides a research contribution (it solves a previously unsolved and important business problem, or improves upon an existing  solution for a solved problem), the study is scientifically rigorous (but not so rigorous that it ceases to be relevant to practitioners), the study describes the problem space and the search mechanism the researchers used to generate their artifacts, and finally the authors communicate their results to practitioners and IS researchers both.

By rigor, I mean that the researchers base their design firmly in the IS knowledge base, and choose appropriate methods and theories from it when defining and searching their problem space, and in designing their artifacts.  The emphasis, however, should be on creating implementable artifacts that solve problems in a real world environment, and so researchers should refrain from overly simplifying the problem space in order to be more rigorous.

By evaluate, I mean that the researcher should test the design appropriately in the context in which it was meant to be used, and using appropriately rigorous metrics.    In the case of instantiations, fundamentally the researcher is investigating the utility that the artifact brings: how well does it work, and in what contexts.

In comparison with social science (behavioral) research, design science is a proactive research method: we look for a problem, attempt to provide a solution, and determine whether we were successful, how well we were successful, and in what contexts.   Behavioral science is reactive.  It looks at existing solutions and attempts to understand why a solution works or does not work.  In this way, design science and behavioral science are natural partners, and can work cyclically.   A design science study solves a problem, and a later behavioral science study tries to understand why the solution works.

Firms around the world have become interested in enterprise architecture over the last several years.  In this essay, I define enterprise architecture, describe why we care about it, and how a firm goes about forming one.  I include the business and technical implications of an enterprise architecture on the functioning and structure of a business.

An enterprise architecture is a high level plan drawn in visual form that relates core business processes, enterprise data sources,  key technologies and key customers.   Companies make enterprise architectures as a way of formalizing how they expect business and IT to be aligned, and as a way of saying what kind of operating model the firm will have: how much will standardization of processes will be used among business units, and how much will key data be shared among business units.    Ross et. al.  in their book Enterprise Architecture as Strategy say that companies should represent their enterprise architecture in the form of a high-level, one page diagram, and that they can use that diagram as a basis for making technology and business decisions.  The enterprise architecture in can serve as both a reflection of how the company currently is operating (so that we can make decisions that maintain that model) or can represent where the company wants its operating model to be (so that we can use our enterprise architecture to decide what changes need to be made to IT and the business in order to bring the current operating model in line with what we want.).  The enterprise architecture is about mindfully deciding in how IT is going to be used, because in many ways how IT is going to be used (process standardization and data sharing) can determine the operations of a company, and vice versa.

To show how enterprise architecture influences the operation of the company, I will describe how Ross et. al. use process standardization and data sharing as two axes on a classification grid to classify companies by operating model.    Companies with low standardization and low data sharing are called “diversified” companies.  Business units in such companies perform diverse and non-overlapping functions; each business unit caters to a different set of customers and offers unrelated services to them.   There is little to be gained by standardizing processes and sharing data in such a firm, and the enterprise architecture of such a business would show several parallel sets of processes, systems, technologies and customers.

Companies with high standardization and low data sharing are called “replicated” companies.  Franchises are perfect examples of replicated companies.  In such companies, business processes are highly standardized, but the business units are largely independent and don’t share customers and thus don’t have data integration needs.  IT systems supporting each business unit will be identical or similar, but there will be little or no data sharing.  The enterprise architecture for such a firm would show one set of unified processes

Companies with low standardization and high data sharing are called “coordinated companies.”  Banks and brokerage houses are good examples of coordinated companies, because they offer many different kinds of services in different ways to the same customers.  The enterprise architecture for such a firm would show many different business processes linking to the same data sources and customers.

Finally, there are the unification companies: those with high standardization and high need for data integration.  In such businesses, the many business units all share certain core processes and all need to access the same data.  The enterprise architecture for such a firm would show a common set of processes linking to a common set of data sources and to a common set of customers.

The enterprise architecture can be developed in many ways, and it largely depends on the type of IT governance the firm has.  Ross et. al. don’t recommend that the IT leaders draw up the document themselves, but rather that the business leaders should draw it up with the help of the IT leaders.  The enterprise architecture is a living document, and the framing group should meet periodically to discuss and update it.

The business implications of an enterprise architecture are that it serves as an interface between the IT organization and the business units, and as such is a way to explicitly maintain business/IT alignment.   Since it (hopefully) was created through consensus between the IT organization and the business units, it serves the similar purposes to Broadbent’s business maxims and IT maxims (maxims are statements of strategy that serve to drive initiatives and projects).  Being high level, the enterprise architecture document should allow business leaders to both make decisions about new business opportunities and how to integrate them into the operating model, and to evaluate IT initiatives and projects.  From the IT side, the enterprise architecture serves as a planning tool to evaluate potential IT projects both for how they should integrate into the existing systems, and for how they should relate to customers and business processes.