Inside Architecture

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

  • Inside Architecture

    Systems Architecture Interview Questions


    Next week, I'm interviewing another architect, so I've gone over my list of "things to ask an architect candidate" for another time to see if I'd change anything.  Not much popped out, but I thought I'd share some exercises that I ask architecture candidates to run through. 

    Note: I care more about experience than book learning, but I care very much that you know the actual names for things.   In other words, book learning does matter.  If you never got around to reading any of those 'patterns' books, don't bother to show up.  You wouldn't be considered a qualified medical intern if you referred to the Biceps Brachii as the 'upper arm muscle' and I won't consider you an architect if you can't tell that I'm using a Strategy pattern in my case study.

    The things that a systems architect must do to survive an interview with me:

    • Demonstrate the ability to work on a project team with developers productively
    • Describe a time when you created a vision for a systems architecture, communicate it, and others made it come into existence
    • Tell me how you know when it is time to review code for compliance and when you are better off getting out of a developer's hair
    • Be able to guide and direct the team in the art and science of visual modeling (it's not enough to know... you must also teach).
    • Detect the gaps in the early design artifacts of a project and determine what risks are going unmanaged.
    • Be able to convince me that you understand, in your bones, the concepts of coupling, abstraction, and encapsulation. 
    • Be able to describe at least five GoF patterns in fine detail.  Be able to describe at least five messaging patterns in fine detail.
    • Pick a single system quality attribute that should be paramount in a particular situation, and then explain why.

    Some exercises to run folks through:

    A. James is an IT architect working with a team of 5 developers and 5 testers on a new system.  He has a situation with his development team.  He presented the high-level design for their new system at a dev meeting and the team listened politely.  Then, after reviewing his diagrams, some of the members of the dev team concluded that he has created a great deal of complexity in one area that they think is overkill.  James hears about it from the project manager three days later.  He feels pretty strongly that the complexity is called for.  Evaluate the situation.  What dynamics are at play?  James comes to you for advice: what do you tell him?

    B. Let's say that you have 10 systems in an infrastructure.  One of them provides the list of all customers, while another provides the list of all orders.  You want to keep the systems as decoupled as possible but they need to share data in real time.  What mechanisms do you put in place to keep the systems independent, yet fully integrated?  Describe the steps you would follow to replace the system that holds orders.

    C. Draw the architecture of one of your most complex systems on the white board.  Now:

    • What made you partition the system in this way?
    • What data entities are mastered by your system?  Which components are responsible for actually writing the key data about each entity?
    • What changes do you predict the business will want in the next 2-5 years in this system?  How will the architecture cope with those changes?
    • What system quality attributes did you consider most paramount when designing this system?  What attributes did you sacrifice?

    D. The architectural council has invited you to join.  They perform periodic reviews on major projects.  You attend and a project comes before the council that has not been reviewed before.  It is a medium-sized project for your company (your company will perform between three and six projects of this size each year on average).  It consumes data from other systems in real time, creates transactions in other systems, and produces data for reporting.  The following artifacts are provided.  What additional information do you ask for?  What risks are you concerned about? 

    • Logical Data Model showing every data entity in the system's database
    • Deployment Diagram
    • Class-level architectural diagram illustrating the use of design patterns

    E. You review the code of a junior developer, and you see a call where the developer is passing a structure.  The structure contains 25 different values as parameters to the method being called.  The structure is used only to pass parameters to this one method call.  You ask why the call needs so many parameters, and it turns out that it is used in about eight different places in the code, and each one has a slightly different need, so the routine will look to see what parameters are passed to decide what to do.  The code for the method is complex, and contains many examples of code like this:

       if (paramx != null)

    What patterns do you discuss with your junior developer?  What options do you consider?  Do you advise the developer to change the code?  Why?

    F.  Pick one of the following practice areas and describe the ideas and concerns that led to this area of software development practice, what the practice entails, the benefits that can be achieved, and the negative consequences that may be observed by teams engaged in the practice.  Note: I may pick one for you... be prepared to be asked about any of them. (If you were to ask: "why this particular list?" I'd turn that around and ask you why I picked this list... )

    • Service Oriented Architecture
    • Test Driven Development
    • Aspect Oriented Programming
    • Dependency Injection / Inversion of Control
    • Software Factories

    G. Mary is a fellow architect with a problem and she has come to you for advice.  She is producing an impact analysis on a system we will call "Charlie".  The Charlie system gets an hourly feed of data from another system called "Bravo."  The Bravo system is scheduled to be replaced by an altogether new system called "Romeo" that will organize the data in a completely different way.  Unfortunately, this will radically affect the data feed from Bravo to Charlie.  Not only will it vanish, but any feed from Romeo will be structured and organized in a completely different manner than it was before.  Mary needs to develop a roadmap to allow this change to occur.  What advice do you give her?

  • Inside Architecture

    Are Helper Classes Evil?


    First off, a definition: A helper class is a class filled with static methods.  It is usually used to isolate a "useful" algorithm.  I've seen them in nearly every bit of code I've reviewed.  For the record, I consider the use of helper classes to be an antipattern.  In other words, an extraordinarily bad idea that should be avoided most of the time.

    What, you say?  Avoid Helper Classes!?!  But they are so useful!

    I say: they are nearly always an example of laziness.  (At this point, someone will jump in and say "but in Really Odd Situation ABC, There Is No Other Way" and I will agree.  However, I'm talking about normal IT software development in an OO programming language like C#, Java or VB.Net.  If you have drawn a helper class in your UML diagram, you have probably erred).

    Why laziness?  If I have to pick a deadly sin, why not gluttony? :-)

    Because most of us in the OO world came out of the procedural programming world, and the notion of functional decomposition is so easy that we drop to it when we come across an algorithm that doesn't seem to "fit" into our neat little object tree, and rather than understand the needs, analyze where we can get the best use of the technology, and place the method accordingly, we just toss it into a helper class.  And that, my friends, is laziness.

    So what is wrong with helper classes?  I answer by falling back on the very basic principles of Object Oriented Programming.  These have been recited many times, in many places, but one of the best places I've seen is Robert Martin's article on the principles of OO.  Specifically, focus on the first five principles of class design. 

    So let's look at a helper class on the basis of these principles.  First, to knock off the easy ones: 

    Single Responsibility Principle -- A class should have one and only one reason to change -- You can design helper classes where all of the methods related to a single set of responsibilities.  That is entirely possible.  Therefore, I would note that this principle does not conflict with the notion of helper classes at all.  That said, I've often seen helper classes that violate this principle.  They become "catch all" classes that contain any method that the developer can't find another place for.  (e.g. a class containing a helper method for URL encoding, a method for looking up a password, and a method for writing an update to the config file... This class would violate the Single Responsibility Principle).

    Liskov Substitution Principle -- Derived classes must be substitutable for their base classes -- This is kind of a no-op in that a helper class cannot have a derived class. (Note my definition of a helper class is that all members are static).  OK.  Does that mean that helper classes violate LSP?  I'd say not.  A helper class looses the advantages of OO completely, an in that sense, LSP doesn't matter... but it doesn't violate it.

    Interface Segregation Principle -- Class interfaces should be fine-grained and client specific -- another no-op.  Since helper classes do not derive from an interface, it is difficult to apply this principle with any degree of seperation from the Single Responsibility Principle. 

    Now for the fun ones:

    The Open Closed Principle -- classes should be open for extension and closed for modification -- You cannot extend a helper class.  Since all methods are static, you cannot derive anything that extends from it.  In addition, the code that uses it doesn't create an object, so there is no way to create a child object that modifies any of the algorithms in a helper class.  They are all "unchangable".  As such, a helper class simply fails to provide one of the key aspects of object oriented design: the ability for the original developer to create a general answer, and for another developer to extend it, change it, make it more applicable.  If you assume that you do not know everything, and that you may not be creating the "perfect" class for every person, then helper classes will be an anathema to you.

    The Dependency Inversion Principle -- Depend on abstractions, not concrete implementations -- This is a simple and powerful principle that produces more testable code and better systems.  If you minimize the coupling between a class and the classes that it depends upon, you produce code that can be used more flexibly, and reused more easily.  However, a helper class cannot participate in the Dependency Inversion Principle.  It cannot derive from an interface, nor implement a base class.  No one creates an object that can be extended with a helper class.  This is the "partner" of the Liskov Substitution Principle, but while helper classes do not violate the LSP, they do violate the DIP. 

    Based on this set of criteria, it is fairly clear that helper classes fail to work well with two out of the five fundamental principles that we are trying to achieve with Object Oriented Programming. 

    But are they evil?  I was being intentionally inflammatory.  If you read this far, it worked.  I don't believe that software practices qualify in the moral sphere, so there is no such thing as evil code.  However, I would say that any developer who creates a helper class is causing harm to the developers that follow. 

    And that is no help at all.

  • Inside Architecture

    Job Description for Business Architecture


    As the result of reading some discussions on the responsibilities of Business Architecture, I got to thinking: How to describe the list of prerequisites for Business Architect, and what is the career ladder that I believe a good BA goes through?

    I did a quick bing search to see if other folks had attempted to answer this question.  While there are a few job postings on various boards, there are surprisingly few discussions of job skills or a job description.  One notable exception was posted in the summer of 2009 on the BPMI site, but that one is not particularly distinct from Enterprise Architect. (see below)  For this blog post, I started with the posting by Geoff Balmes from the BPMI site, made a few edits to clarify the distinction from Enterprise Architect, and posted it here.   

    Qualifications of a Business Architect

    The Business Architect analyzes the activities of a particular business unit or line of business and makes recommendations pertaining to the projects that the business unit should perform, in addition to relevant and timely corrections to the governance structure, business processes, and the structure of business information. This person illustrates the alignment (or lack thereof) between strategic goals and key business decisions regarding products and services; partners and suppliers; organization; capabilities; and key business and IT initiatives. The primary focus of this person’s work includes the analysis of business motivations and business operations, through the use of business analysis frameworks and related networks that link these aspects of the enterprise together. The Business Architect works to develop an integrated view of the business unit, in the context of the enterprise, using a repeatable approach, cohesive framework, and available industry standard techniques.

    The Business Architect reports into business management and works closely with other business architects, enterprise architects, and counterparts in Information Technology. The Business Architect may have supervisory responsibility, possibly acting as coach and mentor to junior colleagues in a similar or reporting role. In addition, the Business Architect works though others at every level of the organization soliciting strategic imperatives from senior leaders and executives, and supporting business unit managers as they leverage business architecture artifacts to create their business plans. Finally, the Business Architect may provide direct input into the governance cycle for the funding, oversight, and realization of business projects.  In that governance role, the business architect helps to insure that business and IT projects are aligned to support the achievement of key goals, that specific business scenarios are considered and that business value is delivered. 


    • Develop a business architecture strategy for the business unit based on a situational awareness of various business scenarios and motivations.
    • Apply a structured business architecture approach and methodology for capturing the key views of the business unit in the context of the enterprise.
    • Capture the tactical and strategic business goals that provide traceability through the organization and are mapped to metrics that provide ongoing governance.
    • Describe the primary business functions of the assigned business unit in the context of the enterprise and distinguish between customer-facing, supplier-related, business execution and business management functions.
    • Enumerate, analyze, catalog, and suggest improvements to the strategic, core and support processes of the business unit, as needed, to support strategic and operational goals.  
    • Define the data elements shared between this business unit and other units in the enterprise and the relationships between those data elements and processes, people, systems, and other data elements.
    • Enumerate, analyze, and suggest improvements to the structural relationships of the business.  This requires the creation and maintenance of an ongoing model of roles, capabilities and business units, the decomposition of those business units into subunits, and the interplay between these units in various business processes, materials, people, and systems.

    Skills and Qualifications

    • A broad, enterprise-wide view of the business and varying degrees of appreciation for strategy, processes and capabilities, enabling technologies, and governance
    • The ability to recognize structural issues within the organization, functional interdependencies and cross-silo redundancies.  Those issues may exist in role alignment, process gaps and overlaps, and business capability maturity gaps
    • The ability to apply architectural principles, methods, and tools to business challenges
    • The ability to assimilate and correlate disconnected documentation and drawings, and articulate their collective relevance to the organization and to high-priority business issues
    • The ability to visualize and create high-level models (rigorous information-rich diagrams) that can be used in future analysis to extend and mature the business architecture
    • Experience developing and using these high-level models as required to collect, aggregate or disaggregate complex and conflicting information about the business
    • Extensive experience planning and deploying either business or IT initiatives (preference for both)
    • Experience modeling business processes using a variety of tools and techniques (preference for BPMN)
    • Exceptional communication skills and the demonstrable ability to communicate appropriately at all levels of the organization; this includes written and verbal communications as well as visualizations
    • The ability to act as liaison conveying information in suitably accurate models between the business unit and their counterparts within Information Technology.  The scope of this information includes business requirements, data constraints, business rules, models of strategy and motivation, processes, accountabilities, and many other business and IT operational needs 
    • Must be a Team player able to work effectively at all levels of an organization with the ability to influence others to move toward consensus.  Must be highly reliable, trustworthy, honest, and commitment oriented
    • Strong situational analysis and decision making abilities

    The Career Ladder of a Business Architect

    Describing the career ladder of a business architect is difficult for many reasons.  This is a new field, and the business architects that I know arrived at their career from different directions and are likely on different trajectories.  What I can say is this: becoming successful at business architecture is an extremely useful skill in many aspects of corporate life, and can provide very useful insight and connections into upper echelons of management. 

    To become a business architect requires strong business skills.  A degree in business is more than helpful… few business architects will succeed without one, although a decade or more of experience in an industry can make up the difference.  Note that I’m not focusing on consultants who perform a business architecture assignment, but rather on full time employees who would be able to perform this role.  A firm understanding of structural models is the next prerequisite skill and this kind of thinking is often found in people who “think visually.”  Look for creative individuals in accounting, marketing, and information technology who can tend to draw diagrams in their presentations that represent the relationships between concepts, people, processes, or business functions.

    Once you have proven successful as a business architect, the next step depends on you.  The obvious next step is to the role of enterprise architect.  To be a successful EA, one should have been successful at one of the key EA roles (Business, Solution, Information, or Technology Architecture) and have a reasonable grasp and appreciation for the other roles.  Not an easy step.

    Another direction for the successful Business Architect is into business management.  A BA can see relationships that most mid-level managers have never been trained to look for, and have a rich understanding of how to use that information. 

    How a Business Architect is different from an Enterprise Architect

    I personally consider an Enterprise Architect as a person who can perform as both Solution Architect (SA) and a Business Architect (as needed) and has some ability as an Information Architect.  In addition, an EA can perform at an enterprise level, something that is NOT required of either an SA or BA.  What this means, in my opinion, is that you should not call yourself an Enterprise Architect unless you have full capability as both a BA and an SA and at least partial capability as an IA.  (No, a course on the Zachman Framework or TOGAF is not sufficient). 

    In Zachman terms, an EA has to be able to perform across ALL ROWS AND COLUMNS of the framework.  A Business Architect doesn’t have to extend below row 2 or perhaps 3, while a Solution Architect usually lives in the lower rows.  An Information Architect, at the enterprise level, must be able to run the gamut of a single column of the Zachman framework. 

  • Inside Architecture

    Placing Architecture Properly into Scrum Processes


    As I’m about to complete my share of a longer engagement on using Lean principles to improve the processes at an online services firm, it occurred to me that the efforts we undertook to properly embed Architecture practices into their Scrum process were novel.  I haven’t seen much written about how to do this in practice, and I imagine others may benefit from understanding the key connection points as well.  Hence this post.

    First off, let me be clear: Agile software development practices are not at all averse to software architecture.  But let’s be clear about what I mean by software architecture.  In an agile team, most decisions are left to the team itself.  The team has a fairly short period of time to add a very narrow feature (described as a user story) to a working base of code and demonstrate that the story works.  The notion of taking a couple of months and detailing out a document full of diagrams that explains the architecture of the system: pretty silly. 

    The value of software architecture is that key decisions are made about the core infrastructure of the system itself: where will generalizations lie?  Will a layered paradigm be used, and if so, what are the responsibilities of each layer?  What modules will exist in each layer and why will they be created? How will the responsibilities of the system be divided up among the layers and components?  How will the modules be deployed at scale?  How will information flow among the modules and between the system and those around it?

    The way these questions are answered will indicate what the architecture of the system is.  There are many choices here, and the “correctness” of any choice is a balance between competing demands: simplicity, security, cost, flexibility, availability, reliability, usability, correctness, and many more.  (These are called “System Quality Attributes”).  Balancing between the system quality attributes takes thought and careful planning.

    So when does this happen in an agile process?

    Let’s consider the architect’s thinking process a little.  In fact, let’s break the software architecture process into layers, so that we can divide up the architectural responsibility a little.  You have three layers of software architectural accountabilities.  (Repeat: I’m talking about Software Architecture, not Enterprise Architecture.  Please don’t be confused.  Nothing in this post is specific to the practice of Enterprise Architecture).  All this is illustrated in the diagram below.  (Click on the diagram to get something a little more readable. 


    At the top, you have the Aligning processes of software architecture.  These processes consider the higher levels of enterprise architecture (specifically the business and information architecture) to create To-Be Software Models of the entire (or relevant) software ecosystem.  If you’ve ever seen a wall chart illustrating two dozen or more software systems with connectors illustrating things like flow of data or dependencies, you’ve seen a model of the type I’m referring to.  Creating and updating these kinds of diagrams is a quarterly or semi-annual process and reflects the gradual changes in the strategy of the enterprise. 

    In the middle, you have the Balancing processes of software architecture.  These processes consider the needs of a single system but only from the level of deciding why the software will be divided up into modules, layers, and components, how that division of responsibility will occur, and what the resulting system will look like when deployed in specific technologies in a specific environment.  All of this can be conveyed in a fairly short document that is rich in diagrams with a small amount of text explaining the choices.  This occurs once when a system is moving forward, and the software architecture can be developed alongside the first couple of sprints as input to the third and subsequent sprints.

    At the bottom, you have the Realization processes of software architecture.  This is where the architecture becomes software, and this is where decisions are made about the choice of specific design patterns, the appropriate level of configurability vs. simplicity, and the ability to demonstrate whether the actual intent of the architecture occurs in practice.  In agile, this layer occurs within the team itself.  The software architect can offer advice about what patterns to use, but it is up to the team to realize that advice and/or decide not to implement it.  The team will very likely implement the software architecture as described, but may choose to improve upon it.

    What does the process look like

    There are many visualizations of scrum running around.  Some are described in books, others in papers or blog posts.  Most share some common elements.  There is a product backlog that, through the magic of sprint planning, the team extracts a subset for the sprint.  This becomes the sprint backlog.  The illustrations then tend to show the various rhythms of Sprint as cycles (sprint cycles and daily cycles), ending with a demonstration and retrospective.

    In order to illustrate and train a team on all elements, including the business analysis elements, we chose to be a bit more explicit about the steps PRIOR to sprint planning, including the processes of creating and improving the stories prior to the start of a sprint.  (as above, click on the image to enlarge it).


    Astute observers will notice that we added a step that we are calling “pre-sprint story review.”  This is a meeting that occurs one week prior to the start of a sprint.  It is called by the product owner and he or she invites “senior chickens” (architects, user experience leads, development and test leads, and any other “non-team” members that want a say in the sprint. 

    In that week prior to sprint planning, those folks, working with the product owner, can improve the stories, add constraints, refine the description and acceptance criteria.  And here’s where the architects get to play.  Architects fulfilling the role of “Balancing” in the model above will have (or can create) an outline document describing the architecture of the software system, and can “link” that document to the SPECIFIC STORIES that are impacted by that design. 

    (Note: assuming you are using a tool like Microsoft’s Team Foundation Server, that fully enables Scrum in multiple forms, this is a nearly trivial activity since a document can be easily linked to any story.  Enough advertising.)

    So is an architect a chicken or a pig?  Answer: depends on what “layer” the architecture is at.  The top two layers are chickens.  The third layer, realization, is done by the team itself.  The person on the team may or may not have the title of “designer".  (I’d prefer that they did not, but that’s just because I believe that ALL team members should be trained to fulfill that role.  In reality, the skill may not be wide spread among team members).  Therefore, the third layer is done by the pigs. 

    I hope this provides some insight into how a team can embed software architecture into their scrum cycles.  As always, I’m interested in any feedback you may wish to share.

  • Inside Architecture

    Civil Engineering Analogy to Enterprise Architecture: Flawed


    It is typical to see comparisons of Civil Engineering to Enterprise Architecture.  A number of papers from Gartner have made the comparison, as have many articles and conference discussions.  I have made the comparison myself.

    It is a somewhat apt analogy.  After all, both EA and Civil Engineering are responsible for setting standards (codes) that constrain the efforts of other architects.

    But this is a limited and flawed analogy as well.  Here is why.

    Civil engineers envision this:


    (Futuristic cityscape from CG4TV)

    Enterprise Architects envision these:


    (Futuristic cityscape from 7 art screen savers)

    Notice a difference?  In the first picture, the buildings are pretty, but they are silos.  They are developed independently and do not interact with one another.  The "shared infrastructure" between these buildings is buried underground... (sewers, electric, phone, etc).  That paradigm has not changed in 100 years!   The only interaction is at ground level, where the front doors are.  The only "suspended" part of the image is a transportation system, but there is no evidence, in the image, that the suspended transportation system interacts with the buildings.  It appears only to avoid running into them.

    The second image shows not only transport systems between buildings, but suspended sections of buildings.  Livable, workable, usable space between the buildings.  The way in and out of each building occurs at multiple places, and those connections are more than just for transportation.  In fact, how would you define a building in this city?   This is more akin to the problems faced by Enterprise Architecture.

    An even better image is one that I couldn't find.  It would have been to show the city in LAYERS, with buildings that support a PLATFORM upon which other buildings are built, or upon which those same buildings are extended, with each layer serving unique functions.  Perhaps the lower layer would include freight transport, the middle layer would perhaps include commercial and office spaces, while the top layer (closest to the sun and fresh air) would include living spaces and solar/wind power generation.

    The civil engineering standards needed to produce a layered city are radically different from those needed to build a traditional city.  You'd need to allow for, or even require, the creation of foundations to support structures that exceed the needs of the bottom layer.  (e.g. a 10 storey building with foundations sufficient for a 60 storey building).  There would have to be a mechanism to insure that costs are not shifted in an unfair manner, and that builders could replace a lower-layer building without affecting the structures above it.

    The point is that civil engineering, in practice, has not made the leap to layered cities.  (apparently, futuristic art has not made that leap either!)  Enterprise Architecture has. 

    This is no criticism of civil engineering!  To be fair, it is simpler to envision layers in the cyber world of an Enterprise Architect, where distance is an abstract notion, you don't have to worry about the deterioration of different materials, and both water and gravity are absent. 

    The analogy between EA standards to building codes is flawed because the systemic constraints that these two professions must create, and the envisioned results they are trying to produce, are radically different from one another.  Comparisons between the professions are interesting, and somewhat instructive, but insufficient to advance the art of either one.

  • Inside Architecture

    How to get rid of circular references in C#


    A refers to B, B refers to A, Why can't we all just get along?

    Every now and again, I see a posting on the newsgroups where someone has created a circular reference in their code structure, and they can't figure out how to get out from under it.  I'm writing this article for those folks (and so I have some place to send them when I run across this problem repeatedly).

    Let's start by describing a ciruclar reference.  Let's say that I have a logging layer that is useful for recording events to a log file or a database.  Let's say that is relies on my config settings to decide where to log things.  Let's also say that I have a config settings library that allows me to write back to my config file...

    //calling app:
    Logging myLogObject = new Logging();
    myLogObject.WriteToLog("We are here!");
    MyConfig cnf = new MyConfig();
    cnf.SetSetting("/MyName","mud", myLogObject);

    The class may look like this:

    public class Logging {
     public Logging()
       MyConfig cnf = new MyConfig();

       LoggingLocation = cnf.GetSetting("//Log/Location");
       if (LoggingLocation == "File")
          // save logs to a file
            // save logs to a database

     public void WriteToLog(String LogMessage, int Severity)
       // write the log message


    If you notice, my little logging app refers to my config file library in the constructor of the logging object.  So now the logging object refers to the config object in code.

    Let's say, however, that we want to write a log entry each time a value is changed in the config file. 

    public class MyConfig
       public MyConfig() { }
       public string GetSetting(string SettingXPath)
          // go get the setting
       public void SetSetting(string SettingXPath, string newValue, Logging myLog)
          // set the string and...
          myLog.WriteToLog("Updated " + SettingXPath + " : " + newValue);

    OK, so I removed most of the interesting code.  I left in the reference, though.  Now the config object refers to the logging object.  Note that I am passing in actual objects, and not using static methods.  You can get here just as easily if you use static methods.  However, digging yourself out requires real objects, as you will see.

    Now, compile them both.  One class will require the other.  If they are in the same assembly, it won't matter.  However, if they are in seperate DLLs, as I want to use them, we have a problem, because neither wants to be the one to compile first.

    The solution is to decide who wins: the config object or the logging object.  The winner will be the first to compile.  It will contain a definition of an interface that BOTH will use.  (Note: you can put the interface in a third DLL that both will refer to... a little more complicated to describe, but the same effect.  I'll let you decide what you like better :-).

    For this example, I will pick the config object as the winner. In this case, the logging object will continue to refer to the config object, but we will break the bond that requires the config object to refer to the logging object.

    Let's add the Interface to the Config object assembly:

    public interface IMyLogging
       void WriteToLog(String LogMessage, int Severity);

    Let's change the code in the call to SetSetting:

       public void SetSetting(string SettingXPath, string newValue, IMyLogging myLog)
          // set the string and...
          myLog.WriteToLog("Updated " + SettingXPath + " : " + newValue);

    You will notice that the only think I changed was the declaration.  The rest of the code is unchanged.

    Now, in the Logging object:

    public class Logging : IMyLogging {
    // the rest is unchanged

    Now, the Logging assembly continues to rely on the config assembly, but instead of just relying on it for the definition of our config class, we also rely on it for the definition of the IMyLogging interface.

    On the other hand, the config class is self sufficient.  It doesn't need any other class to define anything.

    Now, both assemblies will compile just fine.

Page 1 of 106 (636 items) 12345»