Seeking Alpha

Dana Gardner's  Instablog

Dana Gardner
Send Message
Dana Gardner is president and principal analyst at Interarbor Solutions (www.interarbor-solutions.com), an enterprise IT analysis, market research, and consulting firm. Gardner, a leading identifier of software productivity trends and new IT business growth opportunities, honed his skills and... More
My company:
Interarbor Solutions, LLC
My blog:
Dana Gardner's BriefingsDirect
View Dana Gardner's Instablogs on:
  • Hackathon Model Plus Big Data Equals Big Innovation For Thomson Reuters

    The next BriefingsDirect innovation interview explores the use of a hackathon approach to unlock creativity in the search for better use of big data for analytics. We will hear how Thomson Reuters in London sought to foster innovation and derive more value from its vast trove of business and market information.

    The result: A worldwide virtual hackathon that brought together developers and data scientists to uncover new applications, visualizations, and services to make all data actionable and impactful.

    Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy.

    To learn more about getting developers on board the big-data analysis train, BriefingsDirect sat down with Chris Blatchford, Director of Platform Technology in the IT organization at Thomson Reuters in London. The discussion is moderated by me, Dana Gardner, Principal Analyst at Interarbor Solutions.

    Here are some excerpts:

    Blatchford: Thomson Reuters is the world's leading source of intelligent information. We provide data across the finance, legal, news, IP, and science, tax, and accounting industries through product and service offerings, combining industry expertise with innovative technology.

    Gardner: It's hard to think of an organization where data and analysis is more important. It's so core to your very mission.

    Blatchford

    Blatchford: Absolutely. We take data from a variety of sources. We have our own original data, third-party sources, open-data sources, and augmented information, as well as all of the original content we generate on a daily basis. For example, our journalists in the field provide original news content to us directly from all over the globe. We also have third-party licensed data that we further enrich and distribute to our clients through a variety of tools and services.

    Gardner: And therein lies the next trick, what to do with the data once you have it. About this hackathon, how did you come up upon that as an idea to foster innovation?

    Big, Open, Linked Data

    Blatchford: One of our big projects or programs of work currently is, as everyone else is doing, big data. We have an initiative called BOLD, which is Big, Open, Linked Data, headed up by Dan Bennett. The idea behind the project is to take all of the data that we ingest and host within Thomson Reuters, all of those various sources that I just explained, stream all of that into a central repository, cleanse the data, centralize it, extract meaningful information, and subsequently expose it to the rest of the businesses for use in their specific industry applications.

    As well as creating a central data lake of content, we also needed to provide the tools and services that allow businesses to access the content; here we have both developed our own software and licensed existing tools.

    So, we could demonstrate that we could build big-data tools using our internal expertise, and we could demonstrate that we could plug in third-party specific applications that could perform analysis on that data. What we hadn't proved was that we could plug in third-party technology enterprise platforms in order to leverage our data and to innovate across that data, and that's where HP came in.

    HP was already engaged with us in a number of areas, and I got to speaking with their Big Data Group around their big data solutions. IDOL OnDemand came up. This is now part of the Haven OnDemand platform. We saw some synergies there between what we were doing with the big-data platform and what they could offer us in terms of their IDOL OnDemand API's. That's where the good stuff started.

    Bringing human understanding to the cloud
    Sign up for IDOL on Demand
    Helping developers build a new class of apps

    Gardner: Software developers, from the very beginning, have had a challenge of knowing their craft, but not knowing necessarily what their end users want them to do with that craft. So the challenge -- whether it's in a data environment, a transactional environment or interface, or gaming -- has often been how to get the requirements of what you're up to into the minds of the developers in a way that they can work with. How did the hackathon contribute to solving that?

    Blatchford: That's a really good question. That's actually one of the biggest challenges big data has in general. We approach big data in one of two ways. You have very specific use cases, for example, consider a lawyer working on a particular case for a client, it would be useful for them to analyze prior cases with similar elements. If they are able to extract entities and relevant attributes, they may be able to understand the case final decision, or perhaps glean information that is relevant to their current case.

    Then you have the other approach, which is much more about exploration, discovering new insights, trends, and patterns. That's similar to the the approach we wanted to take with the hackathon -- provide the data and the tools to our developers for them just to go and play with the data.

    We didn't necessarily want to give them any requirements around specific products or services. It was just, "Look, here is a cool platform with some really cool APIs and some capabilities. Here is some nice juicy data. Tell us what we should be doing? What can we come up with from your perspective on the world?"

    A lot of the time, these engineers are overlooked. They're not necessarily the most extroverted of people by the nature of what they do and so they miss chances, they miss opportunities, and that's something we really wanted to change.

    Gardner: It's fascinating the way to get developers to do what you want them to do is to give them no requirements.

    Interesting end products

    Blatchford: Indeed. That can result in some interesting end-products. But, by and large, our engineers are more commercially savvy than most, hence we can generally rely on them to produce something that will be compelling to the business. Many of our developers have side projects and personal development projects they work on outside of the realms of their job requirement. We should be encouraging this sort of behavior.

    Gardner: So what did you get when you gave them no requirements? What happened?

    Blatchford: We had 25 teams that submitted their ideas. We boiled that down to 7 finalists based upon a set of preliminary criteria, and out of those 7, we decided upon our first-, second-, and third-place winners. Those three end results were actually taken, or are currently going through a product review, to potentially be implemented into our product lines.

    The overall winner was an innovative UI design for mobile devices, allowing users to better navigate our content on tablets and phones. There was a sentiment analysis tool, that allowed users to paste in news stories or any news content source on the web and extract sentiment from that news story.

    And the other was more of an internally focused, administrative exploration tool, that allowed us to more intuitively navigate our own data, which perhaps doesn't initially seem as exciting as the other two, but is actually a hugely useful application for us.

    Bringing human understanding to the cloud
    Sign up for IDOL on Demand
    Helping developers build a new class of apps

    Gardner: Now, how does IDOL OnDemand come to play in this? IDOL is the ability to take any kind of information, for the most part, apply a variety of different services to it, and then create analysis as a service. How did that play into the hackathon? How did the developers use that?

    Blatchford: Initially the developers looked at the original 50-plus APIs that IDOL OnDemand provides, and you have everything in there from facial recognition, to OCR, to text analytics, to indexing, all sorts of cool stuff. Those, in themselves, provided sufficient capabilities to produce some compelling applications, but our developers also utilized Thomson Reuters API's and resources to further augment the IDOL platform.

    This was very important, as it demonstrated that not only could we plug in an Enterprise analytics tool into our data, but also that it would fit well with our own capabilities.

    Gardner: And HP Big Data also had a role in this. How did that provide value?

    Five-day effort

    Blatchford: The expertise. We should remember we stood this hackathon up from inception to completion in a little over one month, and that's I think pretty impressive by any measure.

    The actual hackathon lasted for five days. We gave the participants a week to get familiar with the APIs, but they really didn't need that long because the documentation behind the APIs on IDOL OnDemand and the kind of "try it now" functionality it has was amazing. This is what the engineers and the developers were telling me. That's not my own words.

    The Big Data Group was able to stand this whole thing up within a month, a huge amount of effort on HP's side that we never really saw. That ultimately resulted in a hugely successful virtual global hackathon. This wasn't a physical hackathon. This was a purely virtual hackathon the world over.

    Gardner: HP has been very close to developers for many years, with many tools, leading tools in the market for developers. They're familiar with the hackathon approach. It sounds like HP might have a business in hackathons as a service. You're proving the point here.

    For the benefit of our listeners, if someone else out there was interested in applying the same approach, a hackathon as a way of creating innovation, of sparking new thoughts, light bulbs going off in people's heads, or bringing together cultures that perhaps hadn't meshed well in the past, what would you advise them?

    Blatchford: That's a big one. First and foremost, the reason we were successful is because we had a motivated, willing partner in HP. They were able to put the full might of their resources and technology capabilities behind this event, and that along side our own efforts ultimately resulted in the events success.

    That aside, you absolutely need to get the buy-in of the senior executives within an organization, get them to invest into the idea of something as open as a hackathon. A lot of hackathons are quite focused on a specific requirement. We took the opposite approach. We said, "Look, developers, engineers, go out there and do whatever you want. Try to be as innovative in your approach as possible."

    Typically, that approach is not seen as cost effective, businesses like to have defined use cases, but sometimes that can strangle innovation. Sometimes we need to loosen the reins a little.

    There are also a lot of logistical checks that can help. Ensure you have clear criteria around hackathon team size and members, event objectives, rules, time frames and so on. Having these defined up front makes the whole event run much smoother.

    We ran the organization of the event a little like an Agile project, with regular stand-ups and check-ins. We also stood up a dedicated internal intranet site with all the information above. Finally, we set-up user accounts on the IDOL platform early on, so the participants could familiarize themselves with the technology.

    Winning combination

    Gardner: Yeah, it really sounds like a winning combination: the hackathon model, big data as the resource to innovate on, and then IDOL OnDemand with 50 tools to apply to that. It's a very rich combination.

    Blatchford: That's exactly right. The richness in the data was definitely a big part of this. You don't need millions of rows of data. We provided 60,000 records of legal documents and we had about the same in patents and news content. You don't need vast amounts of data, but you need quality data.

    Then you also need a quality platform as well. In this case IDOL OnDemand.The third piece is what's in their heads. That really was the successful formula.

    Bringing human understanding to the cloud
    Sign up for IDOL on Demand
    Helping developers build a new class of apps

    Gardner: I have to ask. Of course, the pride in doing a good job goes a long way, but were there any other incentives; a new car, for example, for the winning hackathon application of the day?

    Blatchford: Yeah, we offered a 1960s Mini Cooper to the winners. No, we didn't. We did offer other incentives. There were three main incentives. The first one, and the most important one in my view, and I think in everyone's view, was exposure to senior executives within the organization. Not just face time, but promotion of the individual within the organization. We wanted this to be about personal growth as much as it was about producing new applications.

    Going back to trying to leverage your resources and give them opportunities to shine, that's really important. That's one of the things the hackathon really fostered -- exposing our talented engineers and product managers, ensuring they are appreciated for the work they do.

    We also provided an Amazon voucher incentive, and HP offered some of their tablets to the winners. So it was quite a strong winning set.

    Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy. Sponsor: HP.

    You may also be interested in:
    Mar 12 2:10 PM | Link | Comment!
  • Explore Synergies Among Major Enterprise Architecture Frameworks With The Open Group

    Welcome to a special BriefingsDirect presentation and panel discussion from The Open Group San Diego 2015, which ran Feb. 2 through Feb. 5.

    The following discussion, which examines the synergy among the major enterprise architecture frameworks, consists of moderator Allen Brown, President and Chief Executive Officer, The Open Group; Iver Band, an Enterprise Architect at Cambia Health Solutions; Dr. Beryl Bellman, Academic Director, FEAC Institute; John Zachman, Chairman and CEO of Zachman International, and originator of the Zachman Framework; and Chris Forde, General Manager, Asia and Pacific Region and Vice President, Enterprise Architecture, The Open Group. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]

    Here are some excepts:

    Iver Band: As an enterprise architect at Cambia Health Solutions, I have been working with the ArchiMate Language for over four years now, both working with and on it in the ArchiMate Forum. As soon as I discovered it in late 2010, I could immediately see, as an enterprise architect, how it filled an important gap.

    Band

    What is the ArchiMate Language? Well, it's a language we use for building understanding across disciplines in an organization and communicating and managing change. It's a graphical notation with formal semantics. It's a language.

    It's a framework that describes and relates the business, application, and technology layers of an enterprise, and it has extensions for modelling motivation, which includes business strategy, external factors affecting the organization, requirements for putting them altogether and for showing them from different stakeholder perspectives.

    You can show conflicting stakeholder perspectives, and even politics. I've used it to model organizational politics that were preventing a project from going forward.

    It has a rich set of techniques in its viewpoint mechanism for visualizing and analyzing what's going on in your enterprise. Those viewpoints are tailored to different stakeholders. And, of course, ArchiMate, like TOGAF, is an open standard managed by The Open Group.

    Taste of Archimate

    This is just a taste of ArchiMate for people who haven't seen it before. This is actually excerpted from the presentation my colleague Chris McCurdy and I are doing at this conference on Guiding Agile Solution Delivery with the ArchiMate Language.

    Zachman

    What this shows is the Business and Application Layers of ArchiMate. It shows a business process at the top. Each process is represented by a symbol. It shows a data model of business objects, then, at the next layer, in yellow.

    Below that, it shows a data model actually realized by the application, the actual data that's being processed.

    Below that, it shows an application collaboration, a set of applications working together, that reads and writes that data and realizes the business data model that our business processes use.

    All in all, it presents a vision of an integrated project management toolset for a particular SDLC that uses the phases that you see across the top.

    We are going to dissect this model, how you would build it, and how you would develop it in an agile environment in our presentation tomorrow.

    I have done some analysis of The Zachman Framework, comparing it to the ArchiMate Language. What's really clear is that ArchiMate supports enterprise architecture with The Zachman Framework. You see a rendering of The Zachman Framework and then you see a rendering of the components of the ArchiMate Language. You see the Business Layer, the Application Layer, the Technology Layer, its ability to express information, behavior, and structure, and then the Motivation and Implementation and Migration extensions.

    So how does it support it? Well, there are two key things here. The first is that ArchiMate models answer the questions that are posed by The Zachman Framework columns.

    For what: for Inventory. We are basically talking about what is in the organization. There are Business and Data Objects, Products, Contracts, Value, and Meaning.

    For how: for process. We can model Business Processes and Functions. We can model Flow and Triggering Relationships between them.

    Where: for the Distribution of our assets. We can model Locations, we can model Devices, and we can model Networks, depending on how you define Location within a network or within a geography.

    For who: We can model Responsibility, with Business Actors, Collaborations, and Roles.

    When: for Timing. We have Business Events, Plateaus of System Evolution, relatively stable systems states, and we have Triggering Relationships.

    Why: We have a rich Motivation extension, Stakeholders, Drivers, Assessments, Principles, Goals, Requirements, etc., and we show how those different components influence and realize each other.

    Zachman perspectives

    Finally, ArchiMate models express The Zachman Row Perspectives. For the contextual or boundary perspective, where Scope Lists are required, we can make catalogs of ArchiMate Concepts. ArchiMate has broad tool support, and in a repository-based tool, while ArchiMate is a graphical language, you can very easily take list of concepts, as I do regularly, and put them in catalog or metrics form. So it's easy to come up with those Scope Lists.

    Bellman

    Secondly, for the Conceptual area, the Business Model, we have a rich set of Business Layer Viewpoints. Like the top of the -- that focus on the top of the diagram that I showed you; Business Processes, Actors, Collaborations, Interfaces, Business Services that are brought to market.

    Then at the Logical Layer we have System. We have a rich set of Application Layer Viewpoints and Viewpoints that show how Applications use Infrastructure.

    For Physical, we have an Infrastructure Layer, which can be used to model any type of Infrastructure: Hosting, Network, Storage, Virtualization, Distribution, and Failover. All those types of things can be modeled.

    And for Configuration and Instantiation, the Application and Technology Layer Viewpoints are available, particularly more detailed ones, but are also important is the Mappings to standard design languages such as BPMN, UML and ERD. Those are straightforward for experienced modelers. We also have a white paper on using the ArchiMate language with UML. Thank you.

    Dr. Beryl Bellman: I have been doing enterprise architecture for quite a long time, for what you call pre-enterprise architecture work, probably about 30 years, and I first met John Zachman well over 20 years ago.

    Brown

    In addition to being an enterprise architect I am also a University Professor at California State University, Los Angeles. My focus there is on Organizational Communications. While being a professor, I always have been involved in doing contract consulting for companies like Digital Equipment Corporation, ASK, AT and T, NCR, then Ptech.

    About 15 years ago, a colleague of mine and I founded the FEAC Institute. The initial name for that was the Federal Enterprise Architecture Certification Institute, and then we changed it to Federated. It actually goes by both names.

    The business driver of that was the Clinger-Cohen Bill in 1996 when it was mandated by government that all federal agencies must have an enterprise architecture.

    And then around 2000, they began to enforce that regulation. My business partner at that time, Felix Rausch, and I felt that we need some certification in how to go about doing and meeting those requirements, both for the federal agencies and the Department of Defense. And so that's when we created the FEAC Institute.
    Beginning of FEAC

    In our first course, we had the Executive Office of the President, US Department of Fed, which I believe was the first Department of the Federal Government that was hit by OMB which held up their budget for not having an enterprise architecture on file. So they were pretty desperate, and that began the first of the beginning of the FEAC.

    Forde

    Since that time, a lot of people have come in from the commercial world and from international areas. And the idea of FEAC was that you start off with learning how to do enterprise architecture. In a lot of programs, including TOGAF, you sort of have to already know a little bit about enterprise architecture, the hermeneutical circle. You have to know what it is to know.

    In FEAC we had a position that you want to provide training and educating in how to do enterprise architecture that will get you from a beginning state to be able to take full responsibility for work doing enterprise architecture in a matter of three months. It's associated with the California State University System, and you can get, if you so desire, 12 graduate academic units in Engineering Management that can be applied toward a degree or you can get continuing education units.

    So that's how we began that. Then, a couple of years ago, my business partner decided he wanted to retire, and fortunately there was this guy named John Zachman, who will never retire. He's a lot younger than all of us in this room, right? So he purchased the FEAC Institute.

    I still maintain a relationship with it as Academic Director, in which primarily my responsibilities are as a liaison to the universities. My colleague, Cort Coghill, is sort of the Academic Coordinator of the FEAC Institute.

    FEAC is an organization that also incorporates a lot of the training and education programs of Zachman International, which includes managing the FEAC TOGAF courses, as well as the Zachman certified courses, which we will tell you more about.

    I'm just a little bit surprised by this idea, the panel, the way we are constructed here, because I didn't have a presentation. I'm doing it off the top, as you can see. I was told we are supposed to have a panel discussion about the synergies of enterprise architecture. So I prepared in my mind the synergies between the different enterprise architectures that are out there.

    For that, I just wanted to make a strong point. I wanted to talk about synergy like a bifurcation between on the one hand, "TOGAF and Zachman" as being standing on one side, whereas the statement has been made earlier this morning and throughout the meeting is "TOGAF and."

    Likewise, we have Zachman, and it's not "Zachman or, but it's "Zachman and." Zachman provides that ontology, as John talks about it in his periodic table of basic elements of primitives through which we can constitute any enterprise architecture. To attempt to build an architecture out of composites and then venting composites and just modeling you're just getting a snapshot in time and you're really not having an enterprise architecture that is able to adapt and change. You might be able to have a picture of it, but that's all you really have.

    That's the power of The Zachman Framework. Hopefully, most of you will attend our demonstration this afternoon and a workshop where we are actually going to have people work with building primitives and looking at the relationship of primitives, the composites with a case study.

    Getting lost

    On the other side of that, Schekkerman wrote something about the forest of architectural frameworks and getting lost in that. There are a lot of enterprise architectural frameworks out there.

    I'm not counting TOGAF, because TOGAF has its own architectural content metamodel, with its own artifacts, but those does not require one to use the artifacts in the architectural content metamodel. They suggest that you can use DoDAF. You can use MODAF. You can use commercial ones like NCR's GITP. You can use any one.

    Those are basically the competing models. Some of them are commercial-based, where organizations have their own proprietary stamps and the names of the artifacts, and the wrong names for it, and others want to give it its own take.

    I'm more familiar nowadays with the governmental sectors. For example, FEAF, Federal Enterprise Architecture Framework Version 2. Are you familiar with that? Just go on the Internet, type in FEAF v2. Since Scott Bernard has been the head, he is the Chief Architect for the US Government at the OMB, he has developed a model of enterprise architecture, what he calls the Architecture Cube Model, which is an iteration off of John's, but he is pursuing a cube form rather than a triangle form.

    Also, for him the FEAF-II, as enterprise architecture, fits into his FEAF-II, because at the top level he has the strategic plans of an organization.

    It goes down to different layers, but then, at one point, it drops off and becomes not only a solution, but it gets into the manufacturing of the solution. He has these whole series of artifacts that pertain to these different layers, but at the lower levels, you have a computer wiring closet diagram model, which is a little bit more detailed than what we would consider to be at a level of enterprise architecture.

    Then you have the MODAF, the DoDAF, and all of these other ones, where a lot of those compete with each other more on the basis of political choices.

    With the MODAF, the British obviously don't want to use DoDAF, they have their own, but they are very similar to each other. One view, the acquisition view, differs from the project view, but they do the same things. You can define them in terms of each other.

    Then there is the Canadian, NAF, and all that, and they are very similar. Now, we're trying to develop the unified MODAF, DoDAF, and NAF architecture, UPDM, which is still in its planning stages. So we are moving toward a more integrated system.

    Allen Brown: Let's move on to some of the questions that folks are interested in. Moving away from what the frameworks are, there is a question here. How does enterprise architecture take advantage of the impact of new emerging technologies like social, mobile, analytics, cloud, and so on?

    Bidirectional change

    John A. Zachman: The change can take place in the enterprise either from the top, where we change the context of the enterprise, or from the bottom, where we change the technologies.

    So technology is expressed in the context of the enterprise, what I would call Rule 4, and that's the physical domain. And it's the same way in any other -- the building architecture, the airplane architecture, or anything. You can implement the logic, the as-designed logic, in different technologies.

    Whatever the technology is, I made an observation that you want to engineer for flexibility. You separate the independent variables. So you separate the logic at Rule 3 from the physics of Rule 4, and then you can change Rule 4 without changing Rule 3. Basically that's the idea, so you can accommodate whatever the emerging technologies are.

    Bellman: I would just continue with that. I agree with John. Thinking about the synergy between the different architectures, basically every enterprise architecture contains, or should contain, considerations of those primitives. Then, it's a matter of which a customer wants, which a customer feels comfortable with? Basically as long as you have those primitives defined, then you essentially can use any architecture. That constitute the synergy between the architectures.

    Band: I agree with what's been said. It's also true that I think that one of the jobs of an enterprise architect is to establish a view of the organization that can be used to promote understanding and communicate and manage change. With cloud-based systems, they are generally based on metadata, and the major platforms, like Salesforce.com as an example. They publish their data models and their APIs.

    So I think that there's going to be a new generation of systems that provide a continuously synchronized, real-time view of what's going on in the enterprise. So the architectural model will model this in the future, where things need to go, and they will do analyses, but we will be using cloud, big data, and even sensor technologies to understand the state of the enterprise.

    Bellman: In the DoDaF 2.0, when that initially came out, I think it was six years ago or so, they have services architecture, a services view, and a systems view. And one of the points they make within the context, not as a footnote, is that they expect the systems view to sort of disappear and there will be a cloud view that will take its place. So I think you are right on that.

    Chris Forde: The way I interpreted the question was, how does EA or architecture approach the things help you manage disruptive things? And if you accept the idea that enterprise architecture actually is a management discipline, it's going to help you ask the right questions to understand what you are dealing with, where it should be positioned, what the risks and value proposition is around those particular things, whether that's the Internet of Things, cloud computing, or all of these types of activities.

    So going back to the core of what Terry's presentation was about is a decision making framework with informed questions to help you understand what you should be doing to either mitigate the risk, take advantage of the innovation, and deploy the particular thing in a way that's useful to your business. That's the way I read the question.

    Impact of sensors

    Band: Just to reinforce what Chris says, as an enterprise architect in healthcare, one of the things that I am looking at very closely is the evaluation of the impact of health sensor technology. Gartner Group says that by 2020, the average lifespan in a developed country will be increased by six months due to mobile health monitoring.

    And so there are vast changes in the whole healthcare delivery system, of which my company is at the center as a major healthcare payer and investor in all sorts of healthcare companies. I use enterprise architecture techniques to begin to understand the impact of that and show the opportunities to our health insurance business.

    Brown: If you think about social and mobile and you look at the entire enterprise architecture, now you are starting to expand that beyond the limits of the organization, aren't you? You're starting to look at, not just the organization and the ecosystem, your business partners, but you are also looking at the impact of bringing mobile devices into the organization, of managers doing things on their own with cloud that wasn't part of the architecture. You have got the relationship with consumers out there that are using social and mobile. How do you capture all of that in enterprise architecture?

    Forde: Allen, if I had the answer to that question I would form my own business and I would go sell it.

    Back in the day, when I was working in large organizations, we were talking about the extended enterprise, that kind of ecosystem view of things. And at that time the issue was more problematic. We knew we were in an extended ecosystem, but we didn't really have the technologies that effectively supported it.

    The types of technologies that are available today, the ones that The Open Group has white papers about -- cloud computing, the Internet of Things, this sort of stuff -- architectures can help you classify those things. And the technologies that are being deployed can help you track them, and they can help you track them not as documents of the instance, but of the thing in real time that is talking to you about what its state is, and what its future state will be, and then you have to manage that information in vast quantities.

    So an architecture can help you within your enterprise understand those things and it can help you connect to other enterprises or other information sources to allow you to make sense of all those things. But again, it's a question of scoping, filtering, making sense, and abstracting -- that key phrase that John pointed out earlier, of abstracting this stuff up to a level that is comprehensible and not overwhelming.

    Brown: So Iver, at Cambia Health, you must have this kind of problem now, mustn't you?

    Provide value

    Band: That's exactly what I am doing. I am figuring out what will be the impact of certain technologies and how our businesses can use them to differentiate and provide value.

    In fact, I was just on a call this morning with JeffSTAT, because the whole ecosystem is changing, and we know that healthcare is really changing. The current model is not financially sustainable, and there is also tremendous amount of waste in our healthcare system today. The executives of our company say that about a third of the $2.7 trillion and rising spent on healthcare in the US doesn't do anyone any good.

    There's a tremendous amount of IT investment in that, and that requires architecture to tie it altogether. It has to do with all the things ranging from the logic with which we edit claims, to the follow-up we provide people with particularly dangerous and consequently expensive diseases. So there is just a tremendous amount going through an enterprise architecture. It's necessary to have a coherent narrative of what the organization needs to do.

    Bellman: One thing we all need to keep in mind is even more dynamic than that, if you believe even a little bit of Kurzweil's possibilities is that -- are people familiar with Ray Kurzweil's 'The Singularity Is Near' -- 2037 will be around the singularly between computers and human beings.

    So I think that the wrap where he argues that the amount of change is not linear but exponential, and so in a sense you will never catch up, but you need an architecture to manage that.

    Zachman: The way we deal with complexity is through classification. I suggest that there is more than one way to classify things. One is one-dimensional classification, taxonomy, or hierarchy, in effect, decompositions, one-dimensional classification, and that's really helpful for manufacturing. From an engineering standpoint of a two-dimensional classification, where we have classified things so that they are normalized, one effect in one place.

    Then if you have the problems identified, you can postulate several technology changes or several changes and simulate the various implications of it.

    The whole reason why I do architecture has to do with change. You deal with extreme complexity and then you have to accommodate extreme change. There is no other way to deal with it. Humanity, for thousands of years, has not been able to figure out a better way to deal with complexity and change other than architecture.

    Forde: Maybe we shouldn't apply architecture to some things.

    For example, maybe the technologies or the opportunity is so new, we need to have the decision-making framework that says, you know what, let's not try and figure out all this, just to self-control their stuff in advance, okay? Let's let it run and see what happens, and then when it's at the appropriate point for architecture, let's apply it, this is a more organic view of the way nature and life works than the enterprise view of it.

    So what I am saying is that architecture is not irrelevant in that context. It's actually there is a part of the decision-making framework to not architect something at this point in time because it's inappropriate to do so.

    Funding and budgeting

    Band: Yeah, I agree that wholeheartedly. If it can't be health solutions, we are a completely agile shop. All the technology development is on the same sprint cycle, and we have three-week sprints, but we also have certain things that are still annual and wonderful like funding and budgeting.

    We live in a tension. People say, well, what are you going to do, what budget do you need, but at the same time, I haven't figured everything out. So I am constantly living in that gap of what do I need to meet a certain milestone to get my project funded, and what do I need to do to go forward? Obviously, in a fully agile organization, all those things would be fluid. But then there's financial reporting, and we would also have to be fluid too. So there are barriers to that.

    For instance, the Scaled Agile Framework, which I think is a fascinating thing, has a very clear place for enterprise architecture. As Chris said, you don't want to do too much of it in advance. I am constantly getting the gap between how can I visualize what's going to happen a year out and how can I give the development teams what they need for the sprint. So I am always living in that paradox."

    Bellman: The Gartner Group, not too long ago, came up with the concept of emerging enterprise architecture and what we are dealing with. Enterprises don't exist like buildings. A building is an object, but an enterprise is a group of human beings communicating with one another.

    As a very famous organizational psychologist Karl Weick once pointed out, "The effective organization is garrulous, clumsy, superstitious, hypocritical, mostrous, octopoid, wandering, and grouchy." Why? Because an organization is continually adapting, continually changing, and continually adapting to the changing business and technological landscape.

    To expect anything other than that is not having a realistic view of the enterprise. It is emerging and it is a continually emerging phenomena. So in a sense, having an architecture concept I would not contest, but architecting is always worthwhile. It's like it's an organic phenomena, and that in order to deal with that what we can also understand and have an architecture for organic phenomena that change and rapidly adapt.

    Brown: Chris, where you were going follows the lines of what great companies do, right?

    There is a great book published about 30 years ago called 'In Search of Excellence.' If you haven't read it, I suggest that people do. Written by Peters and Waterman, and Tom Peters has tried for ever since to try and recreate something with that magic, but one of the lessons learned was what great companies do, is something that goes simultaneous loose-tight properties. So you let somethings be very tightly controlled, and other things as are suggesting, let them flourish and see where they go before I actually box them in. So that's a good thought.

    So what do we think, as a panel, about evolving TOGAF to become an engineering methodology as well as a manufacturing methodology?

    Zachman: I really think it's a good idea.

    Brown: Chris, do you have any thoughts on that?

    Interesting proposal

    Forde: I think it's an interesting proposal and I think we need to look at it fairly seriously. The Open Group approach to things is, don't lock people into a specific way of thinking, but we also advocate disciplined approach to doing things. So I would susspect that we are going to be exploring John's proposal pretty seriously.

    Brown: You mentioned in your talk that decision-making process is a precondition, the decision-making process to govern IT investments, and the question that comes in is how about other types of investments including facilities, inventory and acquisitions?

    Forde: The wording of the presentation was very specific. Most organizations have a process or decision-making framework on an annual basis or quarterly whatever the cycles are for allocation of funding to do X, Y or Z. So the implication wasn't that IT was the only space that it would be applied.

    However, the question is how effective is that decision-making framework? In many organizations, or in a lot of organizations, the IT function is essentially an enterprise-wide activity that's supporting the financial activities, the plant activities, these sorts of things. So you have the P and Ls from those things flowing in some way into the funding that comes to the IT organization.

    The question is, when there are multiple complexities in an organization, multiple departments with independent P and Ls, they are funding IT activities in a way that may not be optimized, may or may not be optimized. For the architects, in my view, one of the avenues for success is in inserting yourself into that planning cycle and influencing, because normally the architecture team does not have direct control over the spend, but influencing how that spend goes.

    Over time gradually improving the enterprise's ability to optimize and make effective the funding it applies for IT to support the rest of the business.

    Zachman: Yeah, I was just wondering, you've got to make observation.

    Band: I agree, I think that the battle to control shadow IT has been permanently lost. We are in a technology obsessed society. Every department wants to control some technology and even develop it to their needs. There are some controls that you do have, and we do have some, but we have core health insurance businesses that are nearly a 100 years old.

    Cambia is constantly investing and acquiring new companies that are transforming healthcare. Cambia has over a 100 million customers all across the country even though our original business was a set of regional health plans.

    Build relationships

    You can't possibly rationalize all of everything I want you to pay for on that thing. It is incumbent upon the architects, especially the senior ones, to build relationships with the people in these organizations and make sure everything is synergetic.

    Many years ago, there was a senior architect. I asked him what he did, and he said, "Well, I'm just the glue. I go to a lot of meetings." There are deliverables and deadlines too, but there is a part of consistently building the relationships and noticing things, so that when there is time to make a decision or someone needs something, it gets done right.

    Zachman: I was in London when Bank of America got bought by NationsBank, and it was touted as the biggest banking merger in the history of the banking industry.

    Actually it wasn't a merger, it was an acquisition NationsBank acquired Bank of America and then changed the name to Bank of America. There was a London paper that was observing that the headline you always see is, "The biggest merger in the history of the industry." The headline you never see is, "This merger didn't work."

    The cost of integrating the two enterprises exceeded the value of the acquisition. Therefore, we're going to have to break this thing up in pieces and sell off the pieces as surreptitiously as possible, so nobody will notice that we buried any accounting notes someplace or other. You never see that article. You'll only see the one about the biggest merger.

    If I was the CEO and my strategy was to grow by acquisition, I would get really interested in enterprise architecture. Because you have to be able to anticipate the integration of the cost, if you want to merge two enterprises. In fact, you're changing the scope of the enterprise. I have talked a little bit about the role on models, but you are changing the scope. As soon as you change a scope, you're now going to be faced with an integration issue.

    Therefore you have to make a choice, scrap and rework. There is no way, after the fact, to integrate parts that don't fit together. So you're gong to be faced a decision whether you want to scrap and rework or not. I would get really interested in enterprise architecture, because that's what you really want to know before you make the expenditure. You acquire and obviously you've already blown out all the money. So now you've got a problem.

    Once again, if I was the CEO and I want to grow by acquisition or merger acquisition, I would get really interested in enterprise architecture.

    Cultural issues

    Beryl Bellman: One of the big problems we are addressing here is also the cultural and political problems of organizations or enterprises. You could have the best design type of system, and if people and politics don't agree, there are going to be these kind of conflicts.

    I was involved in my favorite projects at consulting. I was involved in consulting with NCR, who was dealing with Hyundai and Samsung and trying to get them together at a conjoint project. They kept fighting with each other in terms of knowledge management, technology transfer, and knowledge transfer. My role of it was to do an architecture of that whole process.

    It was called RIAC Research Institute in Computer Technology. On one side of the table, you had Hyundai and Samsung. On the other side of the table, you had NCR. They were throwing PowerPoint slides back and forth at each other. I brought up that the software we used at that time was METIS, and METIS modeled all the processes, everything that was involved.

    Samsung said you just hit it with a 2×4. I used to be demonstrating it, rather than tossing out slides, here are the relationships, and be able to show that it really works. To me that was a real demonstration that I can even overcome some of the politics and cultural differences within enterprises.

    Brown: I want to give one more question. I think this is more of a concern that we have raised in some people's minds today, which is, we are talking about all these different frameworks and ontologies, and so there is a first question.

    The second one is probably the key one that we are looking at, but it asks what does each of the frameworks lack, what are the key elements that are missing, because that leads on to the second question that says, isn't needing to understand old enterprise architecture frameworks is not a complex exercise for a practitioner?

    Band: My job is not about understanding frameworks. I have been doing enterprises solution architecture in HP at a standard and diversified financial services company and now at health insurance and health solutions company out for quite a while, and it's really about communicating and understanding in a way that's useful to your stakeholders.

    The frameworks are about creating shared understanding of what we have and where are we going to go, and the frameworks are just a set of tools that you have in your toolbox that most people don't understand.

    So the idea is not to understand everything but to get a set of tools, just like a mechanic would, that you carry around that you use all the time. For instance, there are certain types of ArchiMate views that I use when I am in a group. I will draw an ArchiMate business process view with application service use of the same. What are the business processes you need to be and what are the exposed application behaviors that they need to consume?

    I had that discussion with people on the business who are in IT, and we drove those diagrams. That's a useful tool, it works for me, it works for the people around me, it works in my culture, but there is no understanding over frameworks unless that's your field of study. They are all missing the exact thing you need for a particular interaction, but most likely there is something in there that you can base the next critical interaction on.

    Six questions

    Zachman: I spent most of my life thinking about my frameworks. There are six questions you have to answer to have a complete description of whatever it is, what I will describe, what, how, where, who, and why. So that's complete.

    The philosophers have established six transformations interestingly enough, the transfer of idea into an instantiation, so that's a complete set, and I did not invent either one of these, so the six interrogatives. They have the six stages of transformation and that framework has to, by definition, accommodate any factor that's relevant to the existence of the object of the enterprise. Therefore any fact has to be classifiable in that structure.

    My framework is complete in that regard. For many years, I would have been reluctant to make a categorical statement, but we exercised this, and there is no anomaly. I can't find an anomaly. Therefore I have a high level of confidence that you can classify any fact in that context.

    There is one periodic table. There are n different compound manufacturing processes. You can manufacture anything out of the periodic table. That metaphor is really helpful. There's one enterprise architecture framework ontology. I happened to stumble across, by accident, the ontology for classifying all of the facts relevant to an enterprise.

    I wish I could tell you that I was so smart and understood all of these things at the beginning, but I knew nothing about this, I just happened to stumble across it. The framework fell on my desk one day and I saw the pattern. All I did was I put enterprise names on the same pattern for descriptive representation of anything. You've heard me tell quite a bit of the story this afternoon. In terms of completeness I think my framework is complete. I can find no anomalies and you can classify anything relative to that framework.

    And I agree with Iver, that there are n different tools you might want to use. You don't have to know everything about every framework. One thing is, whatever the tool is that you need to deal with and out of the context of the periodic table metaphor, the ontological construct of The Zachman Framework, you can accommodate whatever artifacts the tool creates.

    You don't have to analyze every tool, whatever tool is necessary, if you want to do with business architecture, you can create whatever the business architecture manifestation is. If you want to know what DoDAF is, you can create the DoDAF artifacts. You can create any composite, and you can create any compound from the periodic table. It's the same idea.

    I wouldn't spend my life trying to understand all these frameworks. You have to operate the enterprise, you have to manage the enterprise and whatever the tool is, it's required to do whatever it is that you need to do and there is something good about everything and nothing necessarily does everything.

    So use the tool that's appropriate and then you can create whatever the composite constructs are required by that tool out of the primitive components of the framework. I wouldn't try to understand all the frameworks.

    What's missing

    Forde: On a daily basis there is a line of people at these conferences coming to tell me what's missing from TOGAF. Recently we conducted a survey through the Association of Enterprise Architects about what people needed to see. Basically the stuff came back pretty much, please give us more guidance that's specific to my situation, a recipe for how to solve world hunger, or something like that. We are not in the role of providing that level of prescriptive detail.

    The value side of the equation is the flexibility of the framework to a certain degree to allow many different industries and many different practitioners drive value for their business out of using that particular tool.

    So some people will find value in the content metamodel in the TOGAF Framework and the other components of it, but if you are not happy with that, if it doesn't meet your need, flip over to The Zachman Framework or vice versa.

    John made it very clear earlier that the value in the framework that he has built throughout his career and has been used repeatedly around the world is its rigor, it's comprehensiveness, but he made very clear, it's not a method. There is nothing in there to tell you how to go do it.

    So you could criticize The Zachman Framework for a lack of method or you could spend your time talking about the value of it as a very useful tool to get X, Y, and Z done.

    From a practitioner's standpoint, what one practitioner does is interesting in a value, but if you have a practice between 200 and 400 architects, you don't want everybody running around like a loose cannon doing it their way, in my opinion. As a practice manager or leader you need something that makes those resources very, very effective. And when you are in a practice of that size, you probably have a handful of people trying to figure out how the frameworks come together, but most of the practitioners are tasked with taking what the organization says is their best practice and executing on it.

    We are looking at improving the level of guidance provided by the We are looking at improving the level of guidance provided by the TOGAF material, the standard and guidance about how to do specific scenarios.

    For example, how to jumpstart an architecture practice, how to build a secure architecture, how to do business architecture well? Those are the kinds of things that we have had feedback on and we are working on around that particular specification.

    Brown: So if you are employed by the US Department of Defense you would be required to use DoDAF, if you are an enterprise architect, because of the views it provides. But people like Terri Blevins that did work in the DoD many years, used TOGAF to populate DoDAF. It's a method, and the method is the great strength.

    If you want to have more information on that, there are a number of white papers on our website about using TOGAF with DoDAF, TOGAF with COBIT, TOGAF with Zachman, TOGAF with everything else.

    Forde: TOGAF with frameworks, TOGAF with buy in, the thing to look at is the ecosystem of information around these frameworks is where the value proposition really is. If you are trying to bootstrap your standards practice inside, the framework is of interest, but applied use, driving to the value proposition for your business function is the critical area to focus on.

    You may also be interested in:

    Mar 04 5:15 PM | Link | Comment!
  • Networks: The New Model For B2B Business, A Panel Discussion

    New business networks are unlocking the ability for companies to extend processes and insights broadly and affordably to customers, suppliers, and other partners. As a result, data-savvy B2B participants in these networks are better able to engage with their communities in new and innovative ways.

    Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy.

    The latest BriefingsDirect discussion therefore explores the role and impact of business networks, the often virtual assemblages of interrelated business services, processes, and data that are transforming how companies and consumers conduct commerce.

    We examine the ways that open markets and communities are rapidly becoming business platforms. And we'll see how today's consumer business models -- exemplified by Amazon, Uber, and Airbnb -- are extending to business-to-business (B2B) commerce, allowing buyers and sellers to find and know each other openly -- and accelerate B2B transactions and commerce efficiencies.

    To learn more about the trends that are making business networks more powerful and more important than ever, BriefingsDirect recently sat down with Marshall Van Alstyne, Professor at Boston University School of Management and Research Scientist at the MIT Center for Digital Business, and also Tim Minahan, Chief Marketing Officer SAP Cloud and Line of Business. The panel is moderated by me, Dana Gardner, Principal Analyst at Interarbor Solutions.

    Here are some excerpts:

    Gardner: Professor Van Alstyne, this is a tricky time for companies. It seems that they want to retain what works, the business models that have been tried and proven for them. They like having big margins, of course, but in order to grow and to be part of the future they need to expose themselves to these networks, take some risks, maybe lose margin in the process, but perhaps get scale and automation as a payback.

    How do you view that? How do you see companies adjusting? Is this a cultural thing where some companies will take this plunge and others don't? It does seem to be a perilous time for companies. I hope they're not just freezing in the headlights.

    Van Alstyne: It's a great question. There are a couple of elements and they vary based on the where the company is currently. If it's a relatively virgin market, then it's fairly straightforward for them to invite others in, create the platform, and expand out in that direction. If it's an existing market for them, they really have to worry about managing the cannibalization question.

    I know SAP has also had a very interesting example of that, as you move from on-premise services to hosted services. They're doing a nice job of managing that migration. It's a little bit tricky in terms of how much you expand the market, but you really need to. You have to realize that the scale, the innovation, the customer engagement happens on these business platforms. Long-term, one really doesn't have a choice.

    Platforms vs. products

    One of the arguments that we typically make is that even weak platforms tend to beat very strong products. You can look at any number of examples, whether you take a look at the Blackberry, the Sony Personal PlayStation gaming device, or the Garmin device for GPS.

    All of these functions are effectively absorbed into the platform. If you manage a platform ecosystem, where third parties can add value on your behalf, you'll grow faster. The platforms almost always will be products. So, in the long-term, companies don't have a choice. They have to move in this direction.

    Gardner: So if it's inevitable that you have to change, it sounds to me from what I've seen at SAP, that they're recognizing this. They're dealing with it themselves as a company, but they're trying to put together a safe path for enterprises to expand into the networked economy. At the same time, they can have trusted partners for automating a lot of the behind-the-scenes activity and allowing them to still function within their business verticals to know what their intellectual property is and to extend to it.

    Let's go back to Tim. Am I reading that right, Tim, that SAP is trying to be, in a sense, the arbiter between risk and exploration when it comes to the networked economy?

    Minahan: That's an accurate depiction, Dana. Think about our personal lives. Whether we're engaging family and friends on Facebook, buying a book or a blender on Amazon, or trying to capture transportation services to get downtown during rush hour on Uber, we're experiencing the scale and simplicity and convenience of personal networks.

    We run our daily lives on them now. Unfortunately the business world traditionally has been optimized within the four walls of the enterprise. Companies have invested billions over the past 20 to 30 years in re-engineering their processes and investing in systems to really automate those internal processes and information flows.

    They have created what have become islands of efficiency that work very well, and continue to work well, for those that are highly vertically integrated, but very few are, as we talked about earlier.

    At SAP, we believe that solving this inter-enterprise collaboration challenge is one of the biggest opportunities of our era. We feel that we're well positioned to do that and have been assembling some of these business networks. We've had the acquisition of Ariba and Fieldglass in the area of contingent workforce and, with Concur, now in the area of travel and expense.

    We're complementing that with network extensions of our own, both through the addition of things like the product sustainability network, which leverages the existing connections within the network to help companies better perform tracing and tracking of their products, and the financial services network, which really facilitates and aids payment.

    What we're looking at is an opportunity to extend existing IT infrastructure and business process outside the four walls of the enterprise in the most scalable and efficient way possible, no matter what systems a particular company or their trading partners use, all through a single integration point.

    Integration adapters

    Think about Amazon in your personal lives. You don't worry about integrating tier trading partners or how you are going to sell that. Amazon takes care of that for you. That's the same metaphor that we're attempting to carry through into the business world by providing single standard integration adapters or on-ramps to the network that allow you to manage this virtual enterprise in a highly transparent and highly efficient manner.

    Gardner: Professor Van Alstyne, we've seen a great deal of network effects in business over the past decades. Yet nowadays, the confluence of cloud, mobile, and social and an emphasis on data-driven business processes seems to be accelerating and empowering these shifts. Some organizations call this the Third Platform. How does your research define business platforms, and how are the impacts from these Third Platform technology advancements newly impacting businesses?

    Van Alstyne: I emphasize the network effect as one of the driving forces. Indeed, if we can create a positive feedback loop throughout the network effects, that's where you see the efficiency in the scale happening so quickly.

    In terms of a definition, we focus on two elements of the platform. The first is an open architecture that third parties can build upon.

    The second is the governance rules. How is it that people can participate? Why would they participate? How do you share the profits? How do you resolve conflict? You think about it as a nexus of rules and architecture. If you can put those two things together, you can probably grow an ecosystem that helps to foster and stimulate some of those network effects.

    Gardner: Tim Minahan, SAP has been a pioneer inside the four walls of the enterprise over the years with enterprise resource planning (ERP) and other business applications. Now, it seems as if you're recognizing what Professor Van Alstyne has been describing with these network effects and extending your value and business insight and processes across multiple boundaries, outside the four walls of any given enterprise into entire ecosystems.

    Next productivity wave

    Minahan: We truly believe that the next wave of business productivity is not going to come just within enterprises, but between them. Forty years ago, when SAP arguably invented the whole concept of ERP, businesses were operating much, much differently.

    We showed them a new way to automate their internal information and process flows, but they were organized in a much more vertically oriented fashion. The employees would graduate from college, spend 40 years with the company, get the gold watch, and retire.

    Companies owned most of their infrastructure, their manufacturing facilities, their inventory, their shipping fleets, but certainly this is not your father's business environment anymore. In part, this was accelerated by the recession that we're still emerging from. Companies are less vertically integrated than they were in the past.

    They've adopted more variable operating models. They've outsourced everything from manufacturing to customer service, and they need to reach and compete with companies across the street and on the other side of the world. And this is creating new opportunities, as well as new challenges, for businesses today, and it's increasing demands and expectations on individual functions of their teams.

    You're seeing it everywhere. If you have an iPhone, look on the back. It's designed in California by Apple, but it's built, shipped, and serviced by someone else entirely. Even beyond the physical device, Apple makes most of its revenue from network-based services. iTunes relies heavily on an ecosystem of mobile carriers and artists and studios.

    Now, we're seeing this move into the business world, in which companies need to rapidly organize this virtual enterprise, all these resources of employees, manufacturing capacity, logistics, delivery capacity, and customer service to take advantage of certain market opportunity. Or, they need to adapt very quickly to certain market changes, and the only real way to do that is through a digitally connected network of partners, customers, and supply chain.

    Gardner: As the very nature of corporations change, it's really about relationships, data, and feedback loops. The data-driven organization, is it really about that. Are we losing something, are we gaining something, or both, Tim, as we seek this new definition of a corporation?

    Minahan: We're entering an age where the borders between enterprises are being taken down. Companies are moving toward a model where they're managing pools of resources, whether that's pools of talent around expertise, as you just indicated Dana.

    A third of a typical workforce is no longer on the company payroll. It's contingent, statement of work (SOW) workers. In some industries, it's already more than half. This is fastest growing part of the workforce. HR executives, and I talk with many of them, are beginning to rethink what constitutes the workforce and are looking at pools of talent.

    They need to understand where the skill sets lie, not necessarily what roles someone plays today, what skills they have had in the past and be able to, when a particular opportunity or project arises, assemble that expertise very quickly to address that particular project, and disassemble them just as fast, but retain the knowledge within the enterprise for the next time that comes up.

    The same thing is true if you're organizing a supply chain and need to be able to serve a new market like China. Where do you put your manufacturing? How do you address distribution, value-added taxes, and customer support. Traditionally, the model would have been to go and establish your own manufacturing facilities, build your own local agents, but no longer.

    Now you can quickly assemble and address, or test, a particular market or test a particular product in any given market. Should it work, scale it up. Should it not, scale it down and move on. Networks allow you to achieve this.

    I wanted to go back to something that Professor Van Alstyne said that's critically important. I fully agree that the networks go through phases. The first phase is to connect all the various parties, whether they be people, businesses, merchants, banks or all of the above.

    The second part is to automate their existing processes. What gets really exciting, once you've automated these processes, once you have these parties collaborating or transacting its scale, are the new insights and entirely new services you could enable.

    Transactional information

    Once you have these millions of companies or people transacting at scale, you can see the transactional or relationship information. It could be the generated content that helps all members of the community make more informed decisions whether it's about buying or whether it's about, should I bid on a particular bit of business as a seller or as a bank, mitigating risk in lending to allow them to understated who the buyer is, who the seller is and what their traditional history is.

    That is the ultimate big data opportunity, when you have these networks operating at scale. We're beginning to deliver this networked intelligence in the form of insight services to help our members of the communities make important buying, selling, and financing decisions in ways that they couldn't before.

    Van Alstyne: Dana, let me jump in for a second. One of the things that Tim just said is quite important. One of the most interesting elements of the platform is the extent for new business services and new products to emerge. One of the Silicon Valley descriptions of the platform is that you know you have one when your community takes it in a direction you didn't expect.

    You need to have made it possible for that. The underlying architecture needs the support the ability to develop something new that wasn't expected, but that's one of the ways the platform adapts to create new value.

    The communities start to add new value and new services in ways that the platform meets the needs of the ecosystem, so it's this ability to turn out new sources of value based on the underlying architecture. This is one of the key distinctions of platforms that really do add value.

    Minahan: I totally agree with that. We've only just entered it into this networked economy or networked era. One of the most exciting things is that it allows you to begin to entirely rethink traditional business models that were organized in an era where, to use an economic term, transaction costs were extremely high.

    Look at Uber, what Uber has done, and the challenges we're now seeing around challenging the traditional medallion livery service. That was organized out of a very real concern around safety and issues, but over time, that model matured and unfortunately got very costly.

    What you saw were the medallions being aggregated in the hands of a small few who could afford them. That obviously had some implications on the level of service and cost of service to employers. Now we've removed all of the transaction costs and could add up efficiently match demand -- i.e. you as the traveler -- and supply literally anyone that is a card-carrying member of the Uber service.

    That's an entirely new business model that is fundamentally challenging hundreds of old rules and thoughts about what it means to hail a cab. So let me toss in one additional principle that's often used for design. I'm thinking exactly of the Uber example.

    One of the best ways to view a platform is that you have the best platform and the transaction cost are the lowest. If you can get those lowest transactions, you're going to get more business taking place on that platform. So do whatever you can to see if you can lower those transaction costs to get the business going.

    Looking for signs

    Gardner: So we've taken a look at the inevitability of these networks. We've seen them already very prominent in the business to consumer (B2C) space, consumer activities, and commerce. We've recognized that openness is important. So we have innovation. We also recognized the importance of governance and management.

    So how do we know when we've done this correctly? Is there a sign? Professor Alstyne, you've mentioned a few that describe powerful and successful networks. Do enterprises have to view themselves differently? Do they need to look at participants in their network as a metric rather than just margin and net in gross revenues and incomes? Is there a way to be successful?

    Van Alstyne: Platform businesses behave differently than traditional businesses. Silicon Valley had been using lot of these metrics for engagement. How many new users do you get, and how engaged are they with the platform? It's a wonderful place to start. Let me give you three rules that we like to use for platform design that actually help get the system running smoothly.

    One of them is "frictionless entry." You would like to make it as easy as possible for people to get onboard your platform. It doesn't matter if that user is on the developer side. You want folks to be able to enter the platform as easily as possible.

    The next one is that you need to manage "riskless quality." If anyone can participate, there's a danger that folks who actually get onto the platform don't necessarily add value or they may try to siphon off value. You may worry about lower quality. Atari fell apart as a platform when it got low-quality games on it. Uber has to worry about low-quality drivers. If you're bringing in apps in your ecosystem, your users are going to get a bad experience if they are low-quality apps. So you still need to have riskless quality.

    The first principle is frictionless entry, and you need to manage riskless quality from the users on that side.

    The third one is "permissionless innovation." You don't want your developers to necessarily have to come to you to get permission. There is always this danger because you own the platform. You have enormous power over them and you could simply take that idea and run with it. You need the ecosystem partners to be able to run with an idea and create something novel on their own and let them have that value. They don't need to get permission first.

    These are three rules that we use for design -- frictionless entry, riskless quality, and permissionless innovation. Those are really good guidelines and are helping to get these ecosystems to grow quickly, get more users onboard, and get your value add from third party participation.

    Gardner: Tim Minahan at SAP Cloud, tell us a bit about what you're doing at SAP, some of your acquisitions, besides your cloud, this ability to be frictionless and help people come on the network easily. You recently finished up the Concur acquisition, one of your largest ever. Explain how you're growing the size of your network?

    Application agnostic

    Minahan: What Professor Van Alstyne just talked about are principles that we subscribe to. In a business network sense, it also requires you to be open and application agnostic and largely agnostic to the on-ramps. That's part of the frictionless entry.

    So regardless of what system you are using, whether it's SAP, Ariba, Concur, Oracle, PeopleSoft Info, etc., you need to be able to attach the systems to the network, those demand systems that allow you to connect and collaborate through the network to extend that business process and engage with your customers, suppliers, and other partners.

    Think about our personal lives, whether it's Uber or Amazon, those networks that are most powerful and most impactful on our personal lives allow a seamless process. You don't even think about the process, but it is end to end.

    In the case of Amazon you don't think about the buying process -- how am I going to connect to those individual merchants? They're already connected for you. Ultimately, you believe you're buying from Amazon, but you might be buying from an independent provider and they are still delivering to you.

    Likewise, you don't think about, gee, now that I have placed the order, do I have to call my bank to settle out? No, that's handled for you, SAP has been using these guiding principles to go out and make sure that we're building the network appropriately, both in our organic means through innovation and the introduction of new services, like payments, financing, and dynamic discounting, both independently with other members and financial institutions of the network, as well as inorganically through acquisitions.

    Gardner: As we close out, we've determined that the number of participants and the value of the commerce is super important in these networks. Several times we've also touched on this feedback loop in the data. So as we look to the future, we might have competing networks. If we assume that those networks are going to have some frictionless ability to move on and off of them, then the best network is where people will go.

    Is the best network the one that provides the best insights in data? Can we close out our discussion by looking at the importance of shared data and analysis and the ability to counter that analysis up from these transactions as a differentiator going forward that will pick winners and losers in open commerce network environment, if you will.

    Let's go to Professor Van Alstyne first. Who is going to win in this network environment and is the data and openness and availability of analytics going to be a major determinant of that?

    Van Alstyne: I am going to argue the best platform is the one that creates the most value over time and that probably means that the data analytics, those that can use the data to create these data-driven feedback loops, will be the winners.

    One of the things that I want to emphasize is that frictionless entry and the ability of the movement of data doesn't necessarily mean that switching costs are going to be low or that it's going to be easy to necessarily change networks. Network effects do create winner-take-all markets, they do create these behemoths. Google Search has 67 percent market share in the US and 90 percent in Europe. Facebook has 1.3 billion users. I think Amazon web services has a huge proportion of the cloud services.

    We need to be careful if we think we're going to be able to switch networks easily. There are going to be some very substantial winner-take-all networks and some concentration at the top. Cloud and data is going to be an integral part of that, as the data creates these data-driven feedback loops that support these network effects.

    Data and analytics

    Minahan: I agree with the professor that the key litmus test of who wins is the platform or the network that creates the most value, and I think value comes in a few flavors.

    Number one is relevancy. Are my trading partners there? At SAP, typically about half of any given company's trading partners are already connected in transacting. That makes the frictionless entry that much easier. Think about Facebook. Why would you join any other personal network when most of your friends and family are already there.

    The second is the aspect of value. Can I manage most of my collaborations in a single environment or do I need to join multiple networks in order to complete a transactional process? The more capabilities you can layer in to make it more convenient for all members of the network to collaborate, the more value add.

    And third, I believe that we've only scratched the surface on these insights. I wouldn't even say that it's a two-sided model. It's a multi-sided model, where once you get these parties collaborating at scale, the transactional relationship and community-generated content can deliver new insights to help folks make more informed decisions, whether it's, which trading partners to do business with or which areas of your existing supply chain might be presented with risk in the future and you need to adapt quickly or which financial settlement options you have to settle out to help you optimize cash flow.

    These are new insights that were previously impossible with traditional on-premise and point-to-point integration models and it can only be accomplished in a network model.

    Gardner: I'd like to thank out panel, Marshall Van Alstyne, Professor at Boston University School of Management and Research Scientist at the MIT Center for Digital Business. And I'll alert our readers that there will soon be a new book called "Platform Strategies" out in 2015 from Professor Alstyne and co-authors. Also a big thank you to Tim Minahan, Chief Marketing Officer, SAP Cloud and Line of Business.

    Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy. Sponsor: SAP.

    You may also be interested in:
    Feb 12 3:14 PM | Link | Comment!
Full index of posts »
Latest Followers

StockTalks

More »
Posts by Themes
Instablogs are Seeking Alpha's free blogging platform customized for finance, with instant set up and exposure to millions of readers interested in the financial markets. Publish your own instablog in minutes.