Inside Architecture

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

December, 2006

Posts
  • Inside Architecture

    Taking your name off of a project

    • 2 Comments

    You cannot often choose the projects that you work on.  However, the ones you work on should reflect your principles, your asthetic sensibilities, even with all the compromises that necessarily have to take place between conception and production.

    But when does it get to the point where, like Daniel Libeskind (who removed his name from the Freedom Tower project), you are prepared to take your name off of a project whose demands and compromises alter the design so substantially that it is not your creation any more?

    This is certainly not new.  In the film industry, for many years, when a director wanted to take his name off of a film, it was credited to the psuedonum "Alan Smithee."  That name has racked up quite a career! (see Wikipedia article on Alan Smithee).

    So, what is the line that you won't cross? 

    Perhaps we don't have enough software projects where the architect is well known.  Does anyone care who the architect is?  Honestly, who remembers the name of the architect of the colosseum in Rome?  What about the architect for your home... do you know his name? 

    On the other hand, I can easily imagine a day where software architects compete as individuals, just as building architects and movie directors do, for the right to work on a project of high visibility and importance.

    And I can easily imagine a day when a software architect will want to take his name off of the system. 

  • Inside Architecture

    Internet-wide Services Integration Architecture needed now!

    • 1 Comments

    As I mentioned in a prior blog entry, the lack of a single consensus mechanism for different Software-as-a-Service apps to integrate with each other and with enterprise-oriented software applications (like SAP, Dynamics, Baan, Siebel, Oracle, Clarify and others) is a clear obstacle to the success of Software as a Service.

    I would say that it has always been an obstacle to the success of the software packages themselves, but the SaaS viewpoint adds more fuel to the fire.

    It is expensive and time consuming to create point-integration between every application and every other application.  In Enterprise Architecture, we attempt to address this by creating a canonical mechanism for communicating a single business event, and a shared enterprise service that serves as the interface for that event. 

    In the Internet, we need the same thing.  We need the ability for a SaaS app to generate an event that an internal SAP instance can consume, including the ability for the SAP instance to call back to the SaaS app to get further data about the event or the data owned by that app.

    Of course, if the SaaS vendor is Dynamics Live or Salesforce, then the SAP company has a conflict of interest.  After all, they have their own CRM solution.  Why would they want to integrate with a service-based solution and potentially create more competition for themselves.  Dynamics faces the same conundrum with respect to Dynamics AX and Salesforce.

    To overcome this conflict, it is imperative that we begin, now, to embark on a new approach.  We need a single canonical mechanism for all enterprise app modules to integrate with each other.  If done correctly, each enterprise will be able to pick and choose modules from different vendors and the integration will be smooth and relatively painless. 

    Why?  because if SAP uses 'Mechanism X' to communicate between their financials and CRM, and Dynamics uses 'Mechanism X' as well, then an organization can move from using Dynamics for both modules to using Dynamics for one and SAP for the other, or the other way around, readily. 

    App developers: Think of it this way: The SQL Server management environment has been using a published API to talk to SQL Server for a long time.  (DMO).  Everyone knows that the API works, because SQL tools use it. Therefore, if you want to create a tool for SQL, just write to DMO.  You can replace one component and leave the other, because the interface is public and defended.

    I would like to see a body be created to develop the public interfaces between the major functions in enterprise software, that the body doesn't move forward until a majority of major players in enterprise software sign up (including all three of these: Microsoft, SAP, and Oracle) and commit to supporting it, and using the interface for their own product modules to speak to one another.  The interface has to allow for SaaS modules as well as installed modules to both produce and consume events and data.

    The lack of this consensus creates unnecessary inefficiency, vendor lock-in, and huge levels of waste in the IT business. 

    It's the elephant in the room, folks.  Rosetta is a great start but they didn't have buy-in that the products would change to match the interface.  In effect, they created an expensive 'bag' to attach to the side of any product, but nothing that the products themselves were committed to adopting to communicate between the modules internally. 

    Perhaps we need to threaten with legislation... hmmm...

  • Inside Architecture

    The roadblock to Software As A Service

    • 1 Comments

    Prediction for 2007: The market for Software as a Service is going to peak soon, and then fall off.  In a year, existing players will stabilize and consolodate and one or two players will be profitable, while the rest fall away.

    The promise of Software as a Service (SaaS) is the same as that of the web: no more installation and management of client-pc software.  You could deliver the software as a service, pay for it when you use it, and cancel your subscription at any time.

    So SaaS vendors (a.k.a. Application Service Providers) provided a series of hosted solutions.  The commercial public was expected to sign up, relinquish the desktop app, and agree to be billed for using word processing, e-mail, financials, customer service, and other systems.

    Many folks have.  Goodness only knows that SalesForce.com is a major player in CRM software, so much so that Microsoft has gone directly into competition with Dynamics Live. 

    The problem is that you get the user interface along with the package, whether you like it or not.  Along with that, you may, or may not, get a proprietary interface for integration with your corporate systems.  That limits the ability of the organization to truly integrate the 'service' tool with their infrastructure. 

    Why does this matter?  Because the advantages of SaaS are that it is easy to implement and that you can quit at any time, which puts pressure on the provider to do a good job and constantly innovate.  However, if you cannot quit at any time, because your integration layer doesn't work with the competitor's service offering, then your service provider has no incentive to improve. 

    In addition, any solution, these days, that doesn't come with 'out-of-the-box' integration between major business functions, like financials to CRM integration, is dead on arrival.  However, you cannot expect all financial system vendors to work to integrate with all CRM service-providers.  That would be complex and expensive.  This is no better than expecting the end-customers to figure it out.

    What is needed is a standard, demanded by the consumers of the service, that all service providers in a field MUST sign up for.  To do that, we need a consistent architecture, across ALL SaaS vendors, so that they can write to a defensible interface and so that a SaaS vendor can integrate directly with another SaaS vendor, allowing a company to outsource both CRM and Financials yet have them work together.

    That means Architecture at the Internet level.  Architecture that vendors sign up for.  OASIS is a great place to put it, but the TC for this need doesn't exist there, at least not yet.  Doesn't have to be OASIS.  Could be any other group willing to drive the standard architecture that allows Software as a Service to integrate across the corporate landscape.

    Either we do this as a community or one vendor will do it and force it on the rest of us.  Personally, I like community.

     

  • Inside Architecture

    Declaring architecture in the code

    • 1 Comments

    Code sits below the architecture.  It is not an expression of architecture.  Code realizes architecture, but is constrained by it.  Therefore, it is entirely possible to declare the architecture in the code.

    For example, let's say that we are building a distributed system composed of a user interface and four services.  The user interface calls the services only.  One of the services recognizes a business event and transmits it to an EAI system for distribution to subscribers.

    The services, architecturally, should remain isolated from one another.  We want to declare that... to constrain our code.  We also want to make sure that the user interface is not dependent upon any interface to the services except a declared public services interface.  This dependency needs to be declared and enforced.  In other words, no other dependency is allowed, especially the sharing of class across the service boundary.

    So how would we declare these constraints in our code?  I would prefer to do this visually, because I don't think that architecture can or should be described in some distorted text typical of most 3GL programming languages.  I have no problem if the visual image has an XML representation, or some other computer-readable standardized mechanism, but the developer should access the architecture visually.

    In addition, the architecture should be a starting place for the code.  I would envision that when a developer opens the code for his app, he sees the diagram and uses it to navigate through the project or projects.  Since this is a distributed system, compilation of each component must be fairly seperate, since each component could potentially reside in different systems.

    Unfortunately, it is 1am and I don't have the patience for writing up the diagram at the moment.  I'll slap together an example tomorrow.  I envision the code representation to look something like this (note: this is a revision of this post.  My first attempt was in XML but in hindsight, that wouldn't be part of the code, it would be part of the IDE or config, so I rewrote to something that looks like C#):

    architecture SCRIBE // system name is SCRIBE in this example
    {
          endpoint CustomerEnterpriseService;
          endpoint InvoiceEnterpriseService;

          //by declaring DataLayer to be InProcess, that means that I intend
          // to have the users of this component call it directly in a DLL rather
          // than through service calls.  This is important to SOA.  
         component DataLayer(InProcess)
          {
              layer DataLayer;
              DataLayer.namespace = "contoso.scribe.service.data";
          }

          component UserInterfaceModule
          {
               layer front, service, composition;
               front.namespace = "contoso.scribe.interface.front";
               service.namespace = "contoso.scribe.service";
               composition.namespace = "contoso.scribe.interface.proxy";
               front.maycall(service);
               front.maycall(composition);
               composition.maycall(service);
               composition.channels.add(CustomerEnterpriseService);
               composition.channels.add(InvoiceEnterpriseService);
          }

          component CustomerServiceModule 
                           delivers CustomerEnterpriseService
          {
               layer facade, business;
               facade.namespace = "contoso.scribe.service.customer.facade";
               business.namespace = "contoso.scribe.service.customer.business";
               facade.maycall(business);
               business.maycall(DataLayer);
          }

          component CustomerServiceModule 
                           delivers  InvoiceEnterpriseService
          {
               layer facade, business;
               facade.namespace = "contoso.scribe.service.invoice.facade";
               business.namespace = "contoso.scribe.service.invoice.business";
               facade.maycall(business);
               business.maycall(DataLayer);
          }
    }

    In this example, wildly oversimplistic but illustrative, I have described two services and a user interface layer.  The u/i layer declares its composition layer and the fact that it is calling services.  (.channels.add)  The interactions can then be limited.  If a bit of code in the interface were to directly call code in 'contoso.scribe.service.data', then the system could warn the developer that the interface layer can only call the composition layer or the service layer.  The service layer can call nothing else.  The composition layer is allowed to interact using a service model.

    Perhaps this ties in to Domain Specific Languages somewhat.  My problem is the notion of considering this to be something seperate from the C# or VB.Net languages themselves. 

    We keep building things AROUND our programming languages, but I think we should not omit the potential gains by building WITHIN them as well, so that our compilers can warn a developer when they exceed the architecture. 

    It also means that the architect can do a code review on a single document, the declared architecture, and feel reasonably assured that the document that he or she is looking at actually reflects the intent of the system, because the compiler is working for the architect, to enforce and reassert the architectural intentions if the developers make a mistake.

  • Inside Architecture

    A SOA Infrastructure Reference Model

    • 1 Comments

    I realized that I had been using a reference model, in my head, for a long time when describing the 'moving parts' in a Service Oriented Architecture.  It was time to put those items into a diagram and share it around.  So, here's the current diagram.

    In this diagram, I illustrate the distinctions between:

    Transitive Transaction Store and Services

    Domain Data Management, Repository, and Services

    Thin Consumer, Rich Consumer, Extended Consumer, Proxy Consumer

    Floating Services

    Large Object Messaging Service

    I don't go into a lot of detail outside the diagram (here in the blog post).  I may add another post to follow up.  Comments are very welcome. (click the thumbnail view to enlarge)

    SOA_Reference
  • Inside Architecture

    Pay Attention to the Application Portfolio

    • 0 Comments

    One nice thing about being in Enterprise Architecture: you get to watch as the infrastructure changes.  When you are working on one big project or another, or even a dozen different projects over the course of the year, you only see the changes that you helped to create, but in EA, we have to take a regular inventory.  It is then when you realize all the things that have actually happened the year before.

    And it is then that you sometimes find that the data about your application portfolio doesn't match reality. 

    In our area, we had a small exercise last fall where we were classifying the applications according to whether they were Strategic, Core, Maintain, or Sunset.  It's a part of Application Portfolio Management called Application Segmentation.

    The practice allows the organization to inspect the investments across the portfolio (Project Portfolio Management) to see how many of the investments, or how much of the money, is going towards strategic needs vs. core needs vs. maintenance, etc.  You could even make portfolio decisions, like "of our total budget, we want to spend X% on strategic needs" which could move a few of the projects into, or out of, the Plan of Record (POR).

    Anyway, while doing this exercise, one of my friends in a different group noticed that one of the "apps" in the portfolio wasn't really an app at all.  The PM who had created the entry had been working on a project and thought that "all projects need their own application id" so he created one, even though the project didn't create a new app... it modified one.

    So my friend did the rational thing: he asked that the 'entry' be removed.  Our support manager agreed and the application entry was removed.  Unfortunately, I wasn't aware of this. 

    Now, the end of the year rolls around, and I'm taking my annual inventory and updating models, and I notice that the app is marked as 'retired.'  I know that the functionality is still there.  Few people remember why the app was 'turned off' and my friend's name is not on the entry's log anywhere.  It took about an hour to figure out what was going on.  Once I realized what he had asked for, I agreed with the logic and removed the entries from my models. 

    Point being: Enterprise Architecture is intimately tied to Application Portfolio Management as well as Project Portfolio Management.  Make sure that your processes for review and governance include process points when an application is decommissioned, not just when it is rolled out.  Otherwise, you, too, will spend a few hours, at some later date, trying to track down "what the heck happened to the SNAFU app?"

Page 1 of 3 (13 items) 123