Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

January, 2008

Posts
  • Inside Architecture

    Towards a shared global integration model

    • 19 Comments

    I'm renewing my call, now over a year old, for creating a single model for integrating all open, shared services.

    I'll talk about what this is, and then what benefits we get.

    A Shared Global Integration Model

    The idea behind a shared model is that we can take an abstract view of the way systems "should" interact.  We can create the idea of a bus and a standard approach to using it.

    Shared Framework

    If we have a standard model, then we can allow a customer, say an Enterprise IT department, to purchase the parts they need in a best of breed manner.

    So let's say that in Contoso, we have two systems that provide parts.  In the diagram below, Customer and Product and Marketing functions are provided by one package, while Accounting and Manufacturing and Order Management are provided by another.  They are integrated using a message bus.

    Sample Framework

    The advantage of a standard approach comes when change occurs.  (Yes, Virginia, Change does occur in IT ;-)

    Let's say that a small upstart Internet company creates a set of services that provides some great features in Customer management.  This is healthy competition.  (see the benefits, below).

    Let's say that the CIO of Contoso agrees and wants to move the company to that SaaS product for Customer management.

    Sample Framework 2

    That's the vision. 

    Of course, we can do this without standards.  So why would we want a standard?

    The benefits of a standard approach

    1. Increased Innovation and Investment

    We lower the economic barriers for this product to exist in the first place.  We want a small upstart company to emerge and focus on a single module.  That allows innovation to flourish.

    We, as an industry, should intentionally lower the "barrier to entry" for this company.  We need to encourage innovation.  To remove these barriers, that young company should not have to create all of the modules of a system in order to compete on any one part.  They should be able to create one module, and compete on the basis of that module. 

    2. Quality Transition tools and reduced transition costs

    A standard approach allows the emergence of tools to help move and manage data for the transition from one system to another.  The tools don't have to come from the company that provides the functionality.  This allows both innovation and quality.  A great deal of the expense of changing packages comes from the data translation and data movements required.  Standard tools will radically reduce these costs.

    3. Best of breed functionality for the business

    We want our businesses to flourish.  However, these are commodity services.  Providing accounting services to a business rarely differentiates that business in its market.  On the other hand, the failure to do supporting functions well can really hurt a company.  There is no reason for the existence of an IT department that cannot do this well.  By using standards, we create a commodity market that allows IT to truly meet the needs of the business by bringing in lower cost services for non strategic functions.

    4. Accelerate the Software-as-a-Service revolution

    We, in Microsoft, see a huge shift emerging.  Software as a Service (SaaS) will change the way that our customers operate.  We can sit on the sidelines, like the railroad industry did in the early 1900's, as the emergence of the automobile eventually replaced their market proposition in the US and many other countries.  Or we can invest in the revolution, and give ourselves a seat at the table.  We plan to have a seat at that table. 

    A shared set of service standards can radically accelerate the transition to the SaaS internet.  That is what I'd like to see happen.

    A dependency on a shared information model

    This movement starts with a shared information model, but not a single canonical schema or shared database.  We need to know the names of the data document types, the relationships between them, and how we will identify a single data document.  (I use the vague term "data document" intentionally, so allow me to avoid "defining myself into a corner" at this early stage.)

    By having a shared information model, we can create the "thin middle" that forms the foundation for an IFaP, and middle-out architecture.

    I care about this.  I believe that IT folks should lead the way, not stand by and let vendors define the models and then leave us to run around like crazy people to figure out how to integrate them.  I'd LOVE to see the "integration consulting industry" become irrelevant and unnecessary. 

    It is time.

  • Inside Architecture

    Engineering for Serendipity

    • 8 Comments

    REST is not enough. 

    I just read Steve Vinoski's article "Serendipitous Reuse?" in IEEE Internet Computing magazine.  He makes a great case for why REST is the best approach for integration through the concept of serendipitous reuse.  The goal being to engineer the simplest useful interface for services, which allows the greatest possible opportunities for reuse.  By creating opportunities, then reuse can occur.

    Saying "REST is sufficient for enterprise integration" is like saying "TCP/IP is sufficient for sending email."  Yep.  TCP/IP is great, but without SMTP, it is only part of the stack.  Just like internet-scale e-mail requires more than just TCP/IP, Enterprise integration requires more than REST.    Sure, it's part of the stack, and a good thing, but REST doesn't provide a sufficient level of harmony to achieve enterprise integration.

    Don't get me wrong.  I love REST. Integration based on REST gives you a great way to share some basic operations and minimize coupling on the operation, but coupling exists in data as well.  Decoupling on the operation is step 1, but without similar decoupling in the data, is a partial answer.

    Without a uniform interface for the information, integration based on REST will allow the sharing of operations, but not information.  In short: If you stop at REST, the stack is incomplete.

    The missing part is a consistent set of information semantics.  A key part of my push for a shared global integration model is precisely this: information identification standards and the semantics around how information can be used. 

    Stack

    SOA without an information model fails.  I've said that many times. 

    REST, without an integration model, is no better.  It is certainly no silver bullet. 

    [note: edited: I fixed the reference to the source.  Steve's article was published in Internet Computing Magazine.]

    [note: based on feedback, I've clarified some of the text of this post.]

  • Inside Architecture

    Standards and Innovation

    • 8 Comments

    When I opened my call for a Shared Global Integration Model, I expected some folks to say "we don't need that."  What I didn't expect was the argument that standards are somehow a bad idea.

    It's hard to consider an argument against standards with a straight face.  A basic tenet of the modern age has been to reduce variation to increase quality.  This is a cornerstone of W Edwards Deming's work.  Without standards, the quality revolution that lifted Japan to an economic superpower would not have been possible.

    Standards in technology are not new.  You can get access to information on ANSI Standards dating back to 1978 at the Charles Babbage Institute.  We use standards in nearly every aspect of computing, from the ASCII (1963) and Unicode (1991) character sets to the TCP/IP protocol (1973) to the USB bus (1996) on our systems.  We use MPEG standards to store to share audio and video on our DVD drives.  Even the electricity coming from the wall outlets is delivered according to a standard.

    So the notion that simply creating a standard constrains creativity rings hollow to me.

    Sir Tim Berners-Lee, the father of the World Wide Web, has been speaking about standards for a very long time.  I direct you to a keynote address he gave at the 3GSM Conference in February of 2007.  

    He first spoke about open platforms being "built to enable, not to control."  He continued:

    "So what else does it take to make an open Internet platform?

    What does it take?

    It takes, mainly, common standards. The innovation of the WWW was possible because the standards for TCP/IP were already implemented in an interoperable way all over the planet, in advance of the innovation. TCP/IP wasn't designed with networked hypertext in mind. But it wasn't designed to prohibit it either — it was and is an open platform.

    Web 2.0 community Web sites, eBay, and Flickr are possible because the Web standards, in turn, were widely implemented in an interoperable way, before those innovations. The same for the wikis, like Wikipedia, and blogs, and so on. The Web is a huge platform for innovation because of those standards. Any new genre of communication, any new social networking idea, immediately can gain the value of unexpected re-use by people across the world.

    There is a very important difference in attitude between a foundation technology and — well — let's call it a ceiling technology. A foundation technology is designed to enable innovation, to be the base which will support other even more powerful things to come. A ceiling technology is not. It is designed to provide a value, and for its provider to cash in and cash out. Proprietary music download systems are ceiling technologies to the extent that the technologists design to be also being the only store in town, rather than creating an open market. Though putting a lid on further innovation, they are still providing a service, and making sure they profit from it.

    Ceiling technologies are the end of the road for innovation.

    When you want to make a foundation technology, you need to look ahead. You need to put aside the short term return on investment questions and look at the long term."

    I am not going to pretend that I am of the same stature as Sir Tim Berners-Lee.  I stand in his shadow.

    But with respect to his sentiment, I agree.  He is correct.  It is the creation of a foundational standard that empowers and builds innovation.  Business software lacks that foundational standard.

    The obstacles that inhibit rapid innovation in business software, of the same scale and scope as the web itself... these obstacles are artificial.    One-off integration mechanisms and transaction-only integration standards are obstacles.  They are ceiling technologies, designed to prevent innovation and lock each customer into a single vendor.

    That must end.  The Software + Services trend requires it.  It is time to end the necessity of "vendor-lock-in through unique integration" by standardizing not only "one potential interface" as the Open Applications Group has done with OAGIS, but to go the next step and create a uniform standard model that unifies the platform for business software. 

    In this new standard, each system is constrained in its scope, but not in its features or abilities.  This creates the standard "plug" that allows a new system to be built and for it to plug in to an existing infrastructure. 

    This simple notion, to define the system boundaries along with the integration messages, allowing independent software vendors to create a single solution that will, through SIMPLE and INEXPENSIVE configuration, integrate WIDELY with HUNDREDS of other business software products, whether as an installed system or an Internet-available service. 

    Two SaaS providers can easily compete with Microsoft and Oracle and one another, and customers benefit from the inevitable competition on reliability, price, quality, and features. 

    I am a mere customer in this pawn-game.  But as a customer, I call for the "big guys" to step up, sign up, and build for a future that will not only risk the precious "lock-in" model, but will, more importantly, secure the future for the companies that lead the way.

  • Inside Architecture

    The future can be seen, if we decide to look

    • 5 Comments

    Harry "Devhawk" Pierson, whom I'm glad to count among my friends, sent me an e-mail last week.  He mentioned that he was going to post on his blog about why my call for a shared global integration model was a fantasy.  "This will be fun," I thought.  Well, Harry did (See Nicks Flawed Vision).  I would like to take some time to consider his arguments.

    Harry's right about one thing: I don't think small.  I'm far from alone in Microsoft.  "The willingness to take on big challenges and see them through" is one of the company's core values.  Add two more elements to the mix: I am an Enterprise Architect, so I'm PAID to look into the future, and I've been fortunate enough to contribute to the work that Microsoft is doing to build out our Software+Services offering, with is also a future-looking initiative.  Add together these three elements (Culture + EA + SaaS) and you can see why I spend so much time talking about BIG IDEAS.

    And the big stuff that Harry jumped on this time: my call for a Shared Global Integration Model.  Harry provided two arguments that concluded (a) it is not possible to create the model, and (b) the model won't deliver innovation.  I will cover the first argument in this post.  I will cover the second argument, dealing with innovation, in my next post.

    Let's look at Harry's first argument.  I'm filling in some gaps in his argument with things that he did not say.  I'm doing that to make the argument complete in a Logic sense.  (I e-mailed this to Harry, and he didn't object). 

    1. Creating a shared architectural model is difficult and requires a huge investment.
    2. No shared model exists today, so any solution here is going to be speculative.
    3. Since the model is speculative, we will do it wrong, which means we will need to change the architecture many times to get it right.
    4. Each change will cost money.
    5. Therefore, to get to a "sufficiently good" architecture will be expensive and time consuming.
    6. If the integration architecture is not "sufficiently good" then it will hinder the ability of systems to deliver value.
    7. If we take a 'standards' approach, then no system vendor will have a stake in the shared architecture.
    8. System vendors that have no stake in the architecture will not, therefore, invest in making their systems 'fit' since doing so hinders their value proposition, removing economic benefit.
    9. If system vendors do not adopt the architecture, it becomes academic and pointless. 
    10. Therefore, the idea is academic and pointless. 

    There are really two logical arguments here, one feeding the other.  The first is that getting a sufficiently good architecture together will be difficult because it is iterative.  The second is that vendors won't adopt it. 

    Assertion #2 is wrong.  A shared model exists in the Telecommunications industry.  An organization called TMForum has been coordinating various industry players for years, and their needs have driven many iterations of a shared process, application, and technology model that is more mature and more advanced than most of the rest of the world: NGOSS/eTOM. 

    With TMForum, it has been expensive and time consuming, and many iterations have come and gone.  Vendors have struggled, and they have compromised, but their solutions are still able to compete on the basis of value.

    Since their model is pretty good, and they already have vendors that have adopted it, then the conclusion reached in step 8 is incorrect.  That invalidates the entire argument.  (Note to logic fanatics: Disproving Harry's argument does not prove the value of my proposal.  It does prove that Harry's argument is insufficient to counter my proposal.  Someone else may come up with a better argument...)

    With all due respect to the Luddites, market forces have been gathering for years that drive people together to create shared non-vendor-specific solutions.  Harry is right about one key element: these solutions don't come because a vendor foists it on the marketplace.  That part of my original post is not correct.  These solutions come because a handful of big customers demand it.

    Let me clarify one thing: I don't work in the part of Microsoft that writes products.  I work in IT. I represent a big customer, and I'd like all who read this post to consider my voice to be a customer that is demanding the creation of a shared integration infrastructure.  I'd like to get together with other IT folks, in other industries, to create a clarion-call that all SaaS vendors can hear: we demand a pre-integrated architecture, so that we can outsource the commodity aspects of IT, and we can avoid vendor lock-in, especially in the SaaS world.

    The value of SaaS, as a business model, depends on it.

  • Inside Architecture

    Flattened by the flu

    • 3 Comments

    Nothing makes you appreciate your health more than spending a week, flat out sick with the flu.  Just as I'm finally getting over all the coughing, congestion, chills, etc... my wife and kids have all come down with the same thing. 

    And we all had flu shots this year!

    Alas... my hiatus in blogging will probably continue for another week as I take time to shepherd folks to health.

Page 1 of 1 (5 items)