Inside Architecture

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

August, 2005

Posts
  • Inside Architecture

    A Case For and Against the Enterprise Library

    • 16 Comments

    I've been an architect for a while now, but, as far as being an architect within the walls of Microsoft, today was day one.

    Already, I've run into an interesting issue: when it is better to forgo the code of the Enterprise Library and roll your own, vs. using existing code.

    Roll your own what?  Well, the MS Enterprise Library is a set of source code (in both VB.Net and C#) that provides an infrastructure for business applications.  The "blocks" that are provided include: caching, configuration, data access and instrumentation, among others.

    I know that many people have downloaded the application blocks.  I don't know how many people are using them.  I suspect far fewer.

    I took a look at the blocks myself, and my first impression: unnecessary complexity.  Big time.  This is what comes of creating a framework without the business requirements to actually use it.  To say that the code has a high "bus" factor is a bit deceptive, because along with the code comes ample documentation that should mitigate the difficulty that will inevitably come from attempt to use them.

    On the other hand, the code is there and it works.  If you have a project that needs a data access layer, why write a new one when a perfectly workable, and debugged, application block exists for it? 

    Why indeed.  I had a long discussion with a developer today about using these blocks.  I will try to recount each of the discussion points:

    1. The blocks are complex and we only need to do something simple.  True: the blocks are complex, but the amount of time needed to do something simple is FAR greater than the amount of time needed to understand how to configure the blocks.  If you look at simple project impact, using something complex is still less expensive that writing something simple.
    2. We don't know these application blocks, so it will take time to learn.  True: but if you write new code, the only person who knows it, when you are done, it you.  Everyone else has to read the documentation.  You'd be hard pressed to come up with better documentation than the docs delivered with the application blocks.
    3. The code we write will meet our needs better because we are doing "special" stuff.  False: the stuff that is done in the application blocks is pure infrastructure.  As an architect, I carry the mantra: leverage existing systems first, then buy for competitive parity, and lastly build for competitve advantage.  You will not normally provide your employer with a competitive advantage by writing your own code in infrastructure.  You are more likely to get competitive advantage by using the blocks, since they will be less expensive with capabilities right out of the box.
    4. We don't need all that code.  True.  Don't use the functionality you don't need.  The cost is very low to ignore the functionality you don't need.  More importantly, writing your own code means debugging your own code.  If you leverage the code that is there, you will not have to debug it.  That saves buckets of time.
    5. Our code can be tuned and is faster than the code in the Enterprise Library.  The code in the Enterprise Library is tuned for flexibility, not speed.  This is true.  However, when you first write your own code, it is slow.  It gets faster when you tune it.  Why not jump right to the tuning step?  Put in the EL for the component you are interested in, run a stress test against it, and fine-tune the code to speed it up.  You have unit tests already in place to prove that your tuning work won't break the functionality (highly valuable when doing perf testing). 

    Please... can someone else come up with any better arguments for NOT using the application blocks in the enterprise library?  I'm not seeing one.

     

  • Inside Architecture

    On Atlas/Ajax and SOA

    • 5 Comments

    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

    Coding Dojo suggestion: the decorator kata

    • 3 Comments

    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

    [fieldname:typename],[fieldname:typename],...,[fieldname:typename]

    For example:
    [name:string],[zipcode:int],[orderdate:date],[ordervalue:decimal]

    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


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

    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.

  • Inside Architecture

    Is it a change request?

    • 3 Comments

    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

    Enterprise Architecture Agility

    • 2 Comments

    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

    Whose name is in the namespace?

    • 2 Comments

    There's more than one way to group your code.  Namespaces provide a mechanism for grouping code in a heirarchical tree, but there is precious little discussion about the taxonomy that designers and architects should use when creating namespaces.  This post is my attempt to describe a good starting place for namespace standards.

    We have a tool: namespaces.  How do we make sure that we are using it well?

    First off: who benefits from a good grouping in the namespace?  I would posit that a good namespace taxonomy benefits the developers, testers, architects, and support teams who need to work with the code.  We see this in the Microsoft .Net Framework, where components that share an underlying commonality of purpose or implementation will fall into the taxonomy in logical places. 

    However, most IT developers aren't creating reusable frameworks.  Most developers of custom business solutions are developing systems that are composed of various components, and which use the common shared code of the .Net Framework and any additional frameworks that may be adopted by the team.  So, the naming standard of the framework doesn't really apply to the IT solutions developer. 

    To start with, your namespace should start with the name of your company.  This allows you to easily differentiate between code that is clearly outside your control (like the .Net framework code or third-party controls) and code that you stand a chance of getting access to.  So, starting the namespace with "Fabrikam" makes sense for the employees within Fabrikam that are developing code.  OK... easy enough.  Now what?

    I would say that the conundrum starts here.  Developers within a company do not often ask "what namespaces have already been used" in order to create a new one.  So, how does the developer decide what namespace to create for their project without know what other namespaces exist?  This is a problem within Microsoft IT just as it is in many organizations.  There are different ways to approach this.

    One approach would be to put the name of the team that creates the code.  So, if Fabrikam's finance group has a small programming team creating a project called 'Motor', then they may start their namespace with: Fabrikam.Finance.Motor.  On the plus side, the namespace is unique, because there is only one 'Motor' project within the Finance team.  On the down side, the name is meaningless.  It provides no useful information.

    A related approach is simply to put the name of the project, no matter how creatively or obscurely that project was named.  Two examples: Fabrikam.Explan or even less instructive: Fabrikam.CKMS.  This is most often used by teams who have the (usually incorrect) belief that the code they are developing is appropriate for everyone in the enterprise, even though the requirements are coming from a specific business unit.  If this includes you, you may want to consider that the requirements you get will define the code you produce, and that despite your best efforts, the requirements are going to ALWAYS reflect the viewpoint of the person who gives them to you.  Unless you have a committee that reflects the entire company providing requirements, your code does not reflect the needs of the entire company.  Admit it.

    I reject both of these approaches. 

    Both of these approaches reflect the fact that the development team creates the namespace, when they are not the chief beneficiary.  First off, the namespace becomes part of the background quickly when developing an application.  Assuming the assembly was named correctly or the root namespace was specified, the namespace becomes automatic when a class is created using Visual Studio (and I would assume similar functionality for other professional IDE tools).  Since folders introduced to a project create child levels within the namespace, it is fairly simple for the original development team to ignore the root namespace and simply look at the children.  The root namespace is simply background noise, to be ignored.

    I repeat: the root namespace is not useful or even important for the original developers.  Who, then, can benefit from a well named root namespace?

    The enterprise.  Specifically, developers in other groups or other parts of the company that would like to leverage, modify or reuse code.  The taxonomy of the namespace could be very helpful for them when they attempt to find and identify functional code that implements the rules for a specific business process.  Include the support team that knows of the need to modify a function, and needs to find out where that function is implemented.

    So, I suggest that it is more wise to adopt an enterprise naming standard for the namespaces in your code in such a way that individual developers can easily figure out what namespace to use, and developers in other divisions would find it useful for locating code by the functional area.

    I come back to my original question: whose name is in the namespace?  In my opinion, the 'functional' decomposition of a business process starts with the specific people in the business that own the process.  Therefore, instead of putting the name of the developer (or her team or her project) into the namespace, it would make far more sense to put the name of the business group that owns the process.  Even better, if your company has an ERP system or a process engineering team that had named the fundamental business processes, use the names of the processes themselves, and not the name of the authoring team.

    Let's look again at our fictional finance group creating an application they call 'Motor.' Instead of the name of the team or the name of the project, let's look to what the application does.  For our example, this application is used to create transactions in the accounts receivable system to represent orders booked and shipped from the online web site.  The fundamental business process is the recognition of revenue. 

    In this case, it would make far more sense for the root namespace to be: Fabrikam.Finance.Recognition (or, if there may be more than one system for recognizing revenue, add another level to denote the source of the recognition transactions: Fabrikam.Finance.Recognition.Web)

    So a template that you can use to create a common namespace standard would be:

    CompanyName.ProcessArea.Process.Point

    Where

    • CompanyName is the name of your company (or division if you are part of a very large company),
    • ProcessArea is the highest level group of processes within your company.  Think Manufacturing, Sales, Marketing, CustomerService, Management, etc.
    • Process is the name of the basic business process being performed.  Use a name that makes sense to the business.
    • Point could be the name of the step in the process, or the source of the data, or the customer of the interaction.  Avoid project names.  Definitely avoid the name of the group that is writing the code.

    In IT, we create software for the business.  It is high time we take the stand that putting our own team name into the software is a lost opportunity at best, and narcissistic at worst.

Page 1 of 2 (8 items) 12