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:
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:
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?
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) do_something_specific(paramx);
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... )
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?
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.
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.
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.
Role 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. Organization 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. Responsibilities 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
Role 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.
Organization 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.
Skills and Qualifications
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.
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.
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.
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:
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.