Inside Architecture

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

Posts
  • Inside Architecture

    How is workflow different from a Finite State Automata?

    • 1 Comments

    After showing a workflow diagram to a co-worker, he asked me if I could tell him how this is any different from basic Finite State Automata (FSA).  To be honest, I had to think about it for a few minutes to get my thoughts around this, but there is a fairly big difference.

    For those of you who aren't familiar with FSA theory, this is a segment of computer science that goes back to the earliest days of computing.  The idea is this: arrange your input into a stream of tokens of the same size.  Then, keeping a state, read each token.  The token will dictate the state you move to next.  Side effects could be added to a transition.  These side effects, taken together, were the actual functional code of the system.

    In a strange way, we've all moved to FSA programming when we moved to event driven application programming.  The event handler is essentially a place to put logic for reacting to an input (the event) in a state (the global environment).  It's a bit different, though, in the sense that our input isn't in a stream.  We can't look ahead at the next token or move in the other direction over a series of tokens (important parts of compilier design).

    In that respect, Workflow modeling is closer to event driven programming than it is to FSA theory, because we don't have that input stream.  We can't look ahead. 

    On the other hand, unlike event driven programming, most workflow systems use the FSA approach to modelling, where you look at the behavior of the system by creating a graph showing the stages of work, and the transitions from stage to stage. 

    However, what really distinguishes Finite State Automata from workflow programming, in my mind, are the three layers of abstraction inherent in Workflow analysis. 

    Finite State Automaton development requires a pre-processing step, where you take the input and interpret it as a series of tokens in a language.  In compiler theory, we call this lexical analysis.  This analysis happens at only one layer of abstraction (usually at a very low level: character sequences).  Therefore, the structure of computer languages has to be represented as a parse tree: a complicated heirarchical structure that "represents" the analyzed token stream.  The FSA is done when the parse tree is done.  It isn't involved in actually using that tree to create the target code.

    With workflow analysis, there are three layers of abstraction: Business unit level, Business process level, and Workstep level.  All three are distinct (but related).  All can be described with rules and constraints.  All have a specific purpose, and each one can be represented as a state graph.  The mathematics are considerably more complex.  (Only the lowest level has to be deterministic).   There are many PhD level practitioners of workflow modeling who can attest to the fact that workflow is much more complicated and complex than the fundamental concept of a Finite State Automaton.

    Why?

    Because FSA's interpret logic... nothing more.

    Workflow modeling deals with human behavior.

  • Inside Architecture

    On XML Models of Process

    • 4 Comments

    XML is an interesting language, but is it a useful one for describing a process?

    We have multiple competing standards for workflow and collaboration.  We have BPEL, XPDL, SWFL, XRL, XScufl, and custom XML workflow models developed for the XFlow, AntFlow, Agile, YAWL, and OpenWFE tools.  (If anyone is looking for a good idea for a masters thesis in Workflow, they should create a comparison of these different languages, catalog features, and create a roadmap for the rest of us).

    Just to add to the fun, rather than learn an existing modelling language, I wrote my own for an internal tool I'm working on.  Wise?  Probably not.  In keeping with the philosophy of the project?  Yes.  Most of the languages I mention above are the creation of committees and have many features designed for multiple vendors to extend the core set.  I needed less (features demanded by existing Java projects) and more (features specific to my Microsoft-based solution).

    I also needed a language feature that I didn't see anywhere else, including on the workflow patterns homepage: native support for ad-hoc workflow.  This means allowing a user the right to change the routing rules in the middle of a workflow process, while the engine maintains managability.  No mean feat. 

    So, inspired by YAWL, and angry at the limitations of the competing partner products that we evaluated, our team wrote another XML based workflow model structure. 

    I learned a few things that I want to share:

    1. XML is an interesting language, but not a forgiving one.  It is easy to create bugs by making small errors in the specification of a schema, where the downstream ripples can be quite large.  If I had to do this all again, I'd better appreciate the time it takes to create and debug the schema itself.
    2. I am far from the first person to tackle the idea of Workflow.  Perhaps it would have been better to start with XPDL (or a subset thereof).  My customers would have a better ability to switch away from my project later, which is one of the stated goals of the project.  I, on the other hand, could have leveraged the built-in workflow experience that comes from leveraging a schema that comes from workflow experts.
    3. XML is an old-fashioned declarative language.  It is about as advanced as C (not C# or Java).  Therefore, while there are many things you can do in XML, you have the freedom to do some pretty stupid stuff.  In addition, you don't have the constructs to do some elegant stuff.  By comparison, XML is an infant.  The effect: the resulting code is difficult for a human being to create, read, follow, analyze, debug, test, or support.
    4. XML parsers are touchy.  They remind me of Fortran-77 compilers.  First error and they are done.  You can't count on an error message from a parser to be all that helpful. 
    5. Tools for generating XML are new, but getting better.  Two commercial tools worth mentioning: Microsoft Infopath (the most underrated, creative, well-built, xml forms system I've seen), and Altova Stylevision (an interesting product that suffers primarily from the lack of imagination of its original designers, not the details of the implementation).  Add Visual Studio for Schema generation and you have almost everything you need.
    6. Automatic mapping between XML and databases: a new and immature field.  The current bits in SQL Server 2000 are OK, but I'm looking forward to better capabilities in Yukon and other tools.  Right now, I wouldn't count on using automatically generated or automatically parsed XML as a way of reducing struggle and pain on a development project.  You will only replace one kind of agony with another.
    7. Like any code-based method, process declaration in XML inherently describes only one aspect of a process: the static connectivity between pre-declared states.  The dynamic aspect is not well described or modeled when you focus on the static.  Some folks have tried to focus on a dynamic model exclusively, but the resulting description was even harder to understand (refer: Biztalk HWS).  In other words, the model, in XML, isn't clean enough to provide to business users.  A LOT of translation is required.  XSLT comes in very handy.
    8. Even with these drawbacks, I can't imagine a better way.

    So, XML it is.   And for now, I'm still using my proprietary schema for workflow models.  Perhaps, someday, I will switch over to BPEL or XPDL.  But not this day.

  • Inside Architecture

    steps to transition a client server VB6 app to .Net

    • 0 Comments

    Every now and again, I get a question that I've seen many times before.  I saw this one recently and thought I'd record the answer, so I can refer to this in the future.

    Question: Our company develops and markets a client/server application which is
    written in VB6 as a rich Win32 Client/Server application. For a variety of
    technological reasons we are looking to migrate toward the .NET environment.  How can we best migrate our VB6 app to the .Net.  We are planning to add a new feature.  Can we plug in the new feature into existing code and maintain a seamless U/I.

    Answer:

    When it is time to add a new module, this may not be the best time to move
    to .net.  I guess it depends on how independent the new module is.  If you need a new module, see step 4. 

    • Step 1: Spend a few days getting used to your code again.  Like an old
      friend that you've lost touch with, code tends to deviate from the design
      during development and maintenance.  Take a fresh look.  Consider this
      question:
      If I was to write an altogether new interface, could I use the same objects
      I currently have?  Would I?
    • Step 2: refactor the existing code, in the existing language.  Clean up any
      of the partitioning problems you saw in step 1.  Some things will still
      creep up in the development later, but taking a little time now to clean up
      the objects can really make a difference in your ability to deliver on a
      predictable basis.
    • Step 3: Create an ENTIRELY NEW USER INTERFACE.  This is not for the faint of
      heart.  However, VB6 has a few advantages that your ordinary application
      doesn't have.  For one thing, all of it's objects comply with the COM
      interface.  Therefore, you can create an entirely new interface in .NET
      without actually removing the old one.  You can pop back and forth, validate
      functionality, and even refactor the old code while writing the new
      interface.  Here is where the work done in Step 2 really pays off.  If your
      business object layer was actually designed to be independent of the U/I
      layer, you will appreciate it today.  If not, you will need to make it
      independent.  There is no way around it.
    • Step 4: retire the old user interface and release the code to business users
      or beta testers.  It takes time to create the new interface.  Someone always
      adds an "innovation" or two.  Start collecting feedback now.  Depending on
      your business, it is perfectly acceptable to actually release the code at
      this stage.  If there are new features to add, do it using the OLD code base
      and the OLD language, called from the new interface.  In other words, keep
      the layers intact.
    • Step 5: Create a parallel data access layer.  This will be used by the .NET
      business objects that you write.  You will continue to use the VB6 Data
      access layer while you still have VB6 components in play.  You will use the
      .NET data layer for .NET objects.  Don't plan on mixing these two... it
      isn't worth it.  (take that from experience and pain... trying to use the
      VB6 data layer from .Net, or vice versa, is a doorway to undue delay and
      gnashing of teeth.)
    • Step 6: Pick a relatively self-contained set of business objects.  Something
      achievable.  Don't go to the biggest, but don't pick the smallest either.
      Give yourself a chance to succeed and still learn.  Recode those business
      objects to .Net.  Have your GUI call them instead of calling the VB6
      objects.  Have the .Net objects call the parallel data access layer.  Learn
      from the experience.
    • Step 7: refactor everything.  Literally, take an entire dev-test cycle to
      just fix the stuff you need to fix.  This could be a month or several
      months, depending on the size and complexity of your app.  Be specific.
      Plan your refactoring.  Do this only to improve structure.  Apply lessons
      learned to the new code, as well as fixes to the interface into the old
      code.
    • Step 8: Release.
    • Step 9: Recode another set of business objects.
    • Step 10: Repeat steps 8 and 9 until all business objects are recoded in
      .NET.  Retire the old VB6 data layer.  Release.
    • Step 11: buy champagne.  Give everyone a week of skiing or windsurfing.
  • Inside Architecture

    On being offered MVP status

    • 4 Comments

    Back when the MVP program first started, I was a developer at American Express.  I was writing code in VB1 and VB2, and the forum was on Compuserve.

    I answered questions regularly, and earned an MVP award.  I kept it up, and remained a VB MVP for three years.  Then, when the dot-com explosion came, I stepped out and took my shot, first at fine.com and then at Acadio.com (which I co-founded).  I simply didn't have time to participate in the forums, although I did miss the interaction.

    Earlier this year, I started to contribute again to the newsgroups, this time to the C# forums.  It is fun and I enjoy it.  I also applied to work at Microsoft.  The dot-com bust had crushed my former employers and I had grown tired of the politics surrounding the government-sector consulting that I was doing. 

    Well, Microsoft took me on, and I've been with one of the IT groups for a number of months now.  However, I did not reveal this fact on the forums.  I didn't want folks asking me questions about their MSDN accounts, or asking me to justify a language feature in C#.  Microsoft is a big place. 

    However, I got a call about a week ago.  Apparently, I had been nominated for MVP in C#.  What an honor!  However, since I was an employee of Microsoft on the day I was nominated, I had to refuse.  Microsoft employees are not eligible for this award.

    Such is life. 

    But it is time to reveal my employer.  So from now on, my signature line on the newsgroups will have the characters [MSFT]. 

    Let's see if I start getting the PSS questions...

  • Inside Architecture

    How to learn Object Oriented Programming

    • 3 Comments

    Do you understand what encapsulation means, but don't know why in the world you would want to use it?
     
    Do you see examples of inheritance in the frameworks and libraries, but have only just dabbled with inheritance in your own code?
     
    If you answered yes to these questions, you want to begin to learn the patterns literature.

    Object oriented programming gives you the tools, but doesn't tell you how to effectively use them. 

    We all just rummage in the dark sometimes, but after a while, some techniques started showing up over and over.  A few years back, a group of clever researchers decided to ask some of the best developers using OO languages what solutions they were coming up with.  If a solution tended to appear over and over, the researchers wrote it down, gave it a name, and described when it would be good to use.

    These recurring solutions are called "design patterns."

    The landmark book that opened up design patterns to the world is called"Design Patterns, Elements of Reusable Object Oriented Software" by Gamma,Helms, Johnson, and Vlissides (a.k.a. the Gang of Four).

    This book is an excellent reference, but not an easy read.  I do not recommend that you start there.  I recommend, instead, that you start with a slim and readable volume called"Design Patterns Explained" by Shalloway and Trott

    These are not code snippets per se, although many books illustrate their examples using bits of code, and I've seen at least one patterns book come with a CD illustrating samples of each pattern (Design patterns in C# byCooper).   Design patterns are not libraries, either.  They are techniques and solutions to the problem of learning and understanding Object Oriented programming.

    Take a look at the Shalloway book.  If you aren't a better programmer after reading that book, I'll eat my hat. (I read it in two days... it's an easy read)

    A list of useful books in the patterns space can be found here:

    http://www.amazon.com/exec/obidos/tg/listmania/list-browse/-/2U7CN56RFJYU3/ref=cm_aya_av.lm_more/104-0692560-9975161

    Good Luck

    (this blog posting was copied from my prior blog.  I find myself referring to it in the forums from time to time, so I wanted to keep it around.)

  • Inside Architecture

    Storing configuration settings for your DLL to use

    • 5 Comments

    One common complaint about the .NET framework is that there is only one config file for the application, even if there are many assemblies (exes and dlls).  This post contains advice for how the author of a DLL can keep the configuration settings for that DLL seperate.

    The config file gets its name from the .EXE, not the DLLs.  Therefore, if your U/I is the EXE (which it usually is), then your dlls will be getting their settings from the config file for the EXE.

    It is often the case, however, that the DLL provides services that can be configured, and that you would want to configure those services differently for each application that uses the DLL.

    On the other hand, if you want to provide a set of "common services" using your object layer, then you can create an XML file that the DLLs will use. So, how does the dll find it's XML file?

    I've answered this question many different ways in different apps, trying things out to see what works.  I've got three answers:

    1. Put the name of the XML file into the registry during install.  The DLL looks to the registry to get the config file name.  This is useful if you are writing a DLL that needs to run from Biztalk or Sharepoint, since you cannot control either their executable or the directory in which they are installed.
    2. Give the XML file a fixed name, hardcoded into dll itself.  Have the DLL look into the application directory (where the EXE lives) to find the XML file.
      • Variation: in the app.config for the EXE, provide a seperate section for the DLL to use.  That section will contain the name of the XML Config file.  If no name is given, use the hardcoded name.  If neither is found, use basic default settings or raise an error in the constructor of your classes.
    3. During install of your app, create a specific directory where nothing but the XML config file will live.  When it comes time to go looking for the file, take the first XML file that you find that lives in that directory.
      This is convenient when transferring your app from dev to test to production, because you can have three files: dev.cml, test.cml, and prod.cml (I renamed xml to cml on purpose). 
      When you install the app, all three are placed in the directory.  The next step in the install is to ask the person doing the install "what environment is this" and, using their response, rename the proper file to the "xml" extension.

    In all three cases, loading an XML is not as difficult as it first appears.

    Take a look at the XSD.EXE tool that is delivered with the .NET SDK (a free download from Microsoft).  Using the XSD tool, you can point at an XML and the tool will generate a class that the XML will deserialize into. 

    Using this class, and the XML deserialization methods built into the framework, you can very easily load the entire XML file into an object that contains other objects.  Now, you can use that object "tree" to inspect your settings very easily. 

    In fact, if you change the values in the settings, it is very easy to save those changes back to the XML config file by simply using the serialization functions (something that is a bit more difficult with the config files).

    I hope this provides useful information.

Page 103 of 106 (631 items) «101102103104105»