Inside Architecture


August, 2005

  • Inside Architecture

    Whose name is in the namespace?










    I reject both of these approaches. 













  • Inside Architecture

    On Atlas/Ajax and SOA


    I ran across a blog entry that attempts to link Atlas/Ajax to SOA.  What absolute nonsense!

    The technology, for those not familiar, is the use of XMLHTTP to link fine-grained data services on a web server to the browser in order to improve the user experience.  This is very much NOT a part of Service Oriented Architecture, since the browser is not a consumer of enterprise services.

    So what's wrong with having a browser consume enterprise web services?  The point of providing SOA services is to be able to combine them and use them in a manner that is consistent and abstracted from the source application(s).  SOA operates at the integration level... between apps.  To assume that services should be tied together at the browser assumes that well formed architecturally significant web services are so fine-grained that they would be useful for driving a user interface.  That is nonsense.

    For an Atlas/Ajax user interface to use the data made available by a good SOA, the U/I will need to have a series of fine-grained services that access cached or stored data that may be generated from, or will be fed to, an SOA.  This is perfectly appropriate and expected.  However, you cannot pretend that this layer doesn't exist... it is the application itself!

    In a nutshell, the distinction is in the kinds of services provided.  An SOA provides coarse-grained services that are self-describing and fully encapsulated.  In this environment, the WS-* standards are absolutely essential.  On the other hand, the kinds of data services that a web application would need in an Atlas/Ajax environment would be optimized to provide displayable information for specific user interactions.  These uses are totally different. 

    If I were to describe the architecture of an application that uses both Atlas/Ajax and SOA, I would name each enterprise web service.  All of the browser services would be named as a single component that provides user interface data services.  The are at different levels of granularity.

    Atlas/Ajax, for better or worse, is an interesting experiment in current U/I circles.  Perhaps XMLHTTP's time has finally come.  However, A/A it will have NO effect on whether SOA succeeds or fails.  Suggesting otherwise demonstrates an amazing lack of understanding of both.


  • Inside Architecture

    The link between strategy and standards


    I blogged a little while back that there is some interest in creating a common naming convention for enterprise web services within the company's IT group.  I've been looking in to this.  One thing that came up: if we don't have consensus on how we tie the EAI strategy to business goals, why should we proceed on a standard? 

    The notion is: if we proceed without a solid connection to business goals, we may lead people in a direction that is ineffective or just plain wrong.  On the other hand, if we wait for strategy to produce basic standards, we will fail to lay good groundwork.  When we do decide to proceed with a common EAI strategy (which is a foregone conclusion), then we will be further behind that we should be. This would slow adoption of common integration patterns across the board.

    Don't get me wrong.  There is a huge amount of integration going on.  However, different strategies are being followed by different groups, and there are literally thousands of home-grown applications being used to run the business.  (That's the problem with having too many developers!) 

    It is my supposition that we could benefit from creating a common strategy for EAI integration that we can evangelize throughout the company's IT division.  I have very strong ideas about how this should look, but I'm not the first, and I'm will not be the last.  Common strategy requires intelligent consensus.  And it will not be free.

    And there is the crux of the issue.  If we spend money, are we doing it wisely?  If so, we should see a business benefit.  In order to understand and measure that benefit, we need to tie to a beneficial business strategy.  In other words, we need to get our ducks in a row and describe the ROI of a common EAI strategy.

    This is coming.  We have a terrific team.  I am truly excited about it.

    So a standard is being created in lieu of a tie to the business strategy, but not as anything enforcable.  Rather, as a de-facto standard that we can share and begin to use, but which we cannot enforce or necessarily encourage until we have some way of knowing if it is the right direction to take.

    And that, folks, is enterprise architecture.

  • Inside Architecture

    Enterprise Architecture Agility


    Can a strategy for Enterprise Application Integration be developed in an iterative manner? 

    I just had a conversation with a very well respected architect who was fairly unconvinced of the positive benefits of using iterative mechanisms to create a common strategy for EAI.  I greatly respect his opinion.  Yet, another architect, who I also respect, felt that iterative development may prove fruitful.

    My opinion: creating a common EAI strategy is not easy.  There are a lot of parts to it.  You have to consider how to deliver advice to a large body of IT developers in multiple timezones.  You have to consider what information should pass across integration boundaries, and how it should be secured.  You have to consider how integrated information will be managed, tracked, and instrumented.  You have to make sure not only that services are provided in a correct manner, but that the correct services are provided.  You have to try to use the technologies that are inexpensive to exploit. 

    When I'm faced with this kind of situation on a project, I will sit down with the customer to understand the needs as best I can, come up with designs that I think may work, and get something back to the customer as soon as I possibly can.  This helps me to prove if I am doing it correctly early, and helps the customer to give me feedback early.  In other words, I don't pretend that I can guess it right.  I guess it and work with the customer to improve.

    So, who is the customer for a common Enterprise Application Integration strategy to cover the enterprise?  Clearly there are business benefits.  Strong ones.  Applications are being integrated all over the company.  But who needs the common strategy to exist, and how can I get something in front of him or her to work towards improvement?  Agile methods work when a customer is present.  Are agile methods appropriate for this kind of activity?

    It's an interesting problem.  I'd love to hear about how this may have played out in other organizations.  If you have an anecdote or experience that you'd like to share about creating a common EAI strategy for the enterprise, please do so.  I love to learn.

  • Inside Architecture

    Is it a change request?


    This is an interesting question in business IT.  I just sat through a long meeting discussing requirements for a project that is under way.  The project started without a detailed list of requirements written out. 

    So, the business adds a requirement that no one was aware of.  I made the mistake of using the words "change request"  which led to a ROUSING discussion.  The business didn't want to start adding "process" when they had not been required to follow a requirements management process to date.  It was a shock to use the words.

    Lesson to learn: if you EVER want to control your Business IT project, don't let any progress to occur without a common agreement about the amount of control, and stick to that agreement as long as possible. 

    There's a layer of stomach lining I'm never getting back.

  • Inside Architecture

    Coding Dojo suggestion: the decorator kata


    I ran across a posting by Robert Martin on the Coding Dojo and I admit to being intrigued.  I'm running a low-priority thread, in the back of my mind, looking for good examples of kata to use in a coding dojo.

    Here's one that I ran across in a programming newsgroup.

    You have an app that needs to be able to read a CSV file.  The first line of the file specifies the data types of the fields in the remaining lines.  The data type line is in the format


    For example:

    you must use a decorator pattern.  The decorator must be constructed using a builder pattern that consumes the data type line.  Output is a file in XML format

       <row><name>Joe Black</name><zipcode>90210</zipcode>... </row>

    Any row that doesn't match the specification will not produce an output line.  The output will pick up with the next line.  The file, when done, must be well-formed.

    Of course, with a kata, the only thing produced at the start is the set of unit tests (and perhaps, in the interest of time, the frame of the classes from a model).  The rest is up to the participants.

    Comments are welcome, of course.

Page 1 of 2 (8 items) 12