Inside Architecture

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

Posts
  • Inside Architecture

    Mort and the Economics of Unmaintainable Code

    • 31 Comments

    I've been called a lot of things in the past few days since I had a public disagreement with many folks over the definition of Mort.  On the surface, it looks like I'm a pretty "out of touch" guy when it comes to the 'common vernacular.' Granted, but looks can be deceiving.  There's more here.  Please bear with me.

    First off, I want to publically apologize to Sam Gentile.  I meant no offense when I asked if he wanted MS to develop BDUF tools.  It was an obviously absurd question, (OK, obvious to me, not obvious to Sam).  I sometimes ask obviously absurd questions when I want to point out that the "logical conclusion" of a line of thinking will take someone where they don't intend to go.  That didn't work on the blog.  My bad. 

    Add to that another mistake: My reading of Sam's message to me was probably incorrect.  In a response I made to a post on Microsoft and Ruby, Sam said:

    I don't think you are getting that point. MSFT is making tools for Morts (the priority) at the expense of every other user (especially Enterprise Developers and Architects). They have nothing for TDD. And I would further contend that making these tools "dumbed down" has significantly contributed to why Morts are Morts in the first place and why they are kept there. Think VB6 and the disatrous code that was unleashed everywhere. If Microsoft took some responsibilty and created tools that advocate good software design principles and supported them then things would be different. You and Peter (which is a friend of mine) are covering the corporate butt. It's a cop out.

    Does it look like Sam is saying "Mort is dumb" or "Mort is bad?"  I thought so at the time.  Perhaps that was not right.  I carried my misreading a bit further.  I read Sam's message to mean, "people who think like Mort thinks are errant."  In hindsight, I believe that Sam meant to say "people who work like Mort works are errant."  The difference is subtle but the result is profound.  Implication: Mort is not a bad person or a stupid person, but the code that Mort produces is not maintainable, and that is bad for all of us.  (I hope I got that right this time).  Sam cares about maintainable code

    To rephrase, the problem is not Mort.  The problem is the unmaintainable code he produces.

    So my apologies to Sam. 

    But was I insane in my conclusions as I've been accused of?  Did I redefine Reality? No.

    First, let me put up a quadrant. 

    Agile Quadrant

    I got the axis values directly from the agile manifesto, so it shouldn't be a surprise to anyone in the agile community. 

    Take a look for a minute and see if there's anything you disagree with.  One thing that may be a bit odd is the entry called "agile tool users without ceremony."  This is for the folks who use agile tools like NUnit and CruiseControl to do development, but don't follow any of the other elements of agile development (like rapid cycles, time-box development, FDD, XP, Scrum, etc).  I don't know how prevalent these folks are, but I've certainly met a few.

    Regardless, look at the values expressed in the Agile Manifesto.  Someone who cares more about "meeting the needs of a user" than they do "following a process" would move up the Y axis.  Someone who cares more about "working software" than they do "comprehensive documentation" would move along the X axis.

    OK... reader... where is Mort?

    Think about it.

    Mort doesn't follow lots of process.  He writes code for one-off applications.  Why?  Because that is why he was hired, and that is what he is paid to do.  He does exactly what his company pays him to do.  Does he write a lot of documentation?  No.  So given those two variables, which quadrant does he fall into?

    The upper right.  The one marked "agile."

    If you wonder why a lot of development managers are unsure of the agile community, it is because this comparison is not lost on them.  Any person who doesn't care for process and who doesn't want to write a lot of documentation can fit in that upper quadrant.  Agile folks are there.

    So is Mort.

    I can hear the chorus of criticism: "That doesn't make Mort agile!"  Hugo is Agile.  Mort is not!

    I'm not done.

    Mort is certainly a problem, because in our world, unmaintainable software is a pain to work with.  Some folks have decided not to hate Mort but to educate him.  (which is good).  The subtle goal here: move Mort's skillset and mindset: help him to value maintainable code. 

    If we do this, and we help Mort grow, will he keep his current job?  Probably not.  He was hired into his current job because he was a Mort.  He was hired because his company values quick fix apps.  Once our intrepid student no longer values unmaintainable code, he will no longer fit in his current positon.  He will find another job.  So what will the company do with the open position?  They will hire someone else and TRAIN THEM TO BECOME ANOTHER MORT.

    Remember, we don't hate Mort.  We have a hard time with his code.  We want to eradicate his code.  But the code is still being developed... by a new Mort.

    There are an infinite supply of new Morts.  Therefore, the solution of "educate Mort" doesn't work to solve the problem of unmaintainable code.  The solution doesn't address the underlying reasons why Mort exists or why his code is bad.  You cannot fight economics with education.  You have to fight economics with economics. 

    Let's look at the economics of unmaintainable code, and think about Mort a little more.

    Code is unmaintainable because it's complexity exceeds the ability of a developer to maintain it.  Would you agree that is a good definition of 'unmaintainable code?' 

    Rather than look at "making code maintainable," what if we look at making code free.  Why do we need to maintain code?  Because code is expensive to write.  Therefore, it is currently cheaper to fix it than rewrite it.  On the other hand, what if code were cheap, or free?  What if it were cheaper to write it than maintain it?  Then we would never maintain it.  We'd write it from scratch every time. 

    Sure, we can choose to write maintainable code.  We can use practices like patterns, object oriented development, and careful design principles.  On the other hand, we can give Mort an environment where he can't hurt himself... where his code is always small because only small amounts of code are needed to get the job done. 

    This is useful thinking here.  If you cannot make sure that Mort will write maintainable code, make him write less code.    Then when it comes time for you (not Mort) to maintain it (he can't), you don't.  You write it again.

    And that is fighting Mort with economics.  Soon, Mort's skill set doesn't matter.  He is writing small amounts of unmaintainable code, and we really won't care.  Someone 'smart' has written the 'hard' stuff for Mort, and made it available as cross cutting concerns and framework code that he doesn't have to spend any time worrying about.  Mort's code is completely discardable.  It's essentially free.

    Hugo cares about quality code.  Mort does not.  In the fantasy world of free code, what value does Hugo bring, and where does Mort fit?  Does Mort put process first or people first?  He puts people first, of course.  He writes the code that a customer wants and gets it to the customer right away.  The customer changes the requirements and Mort responds.  If it sounds like a quick iteration, that is because it is.  This process is fundamentally agile

    Yep. I said it.  In situations where maintainability doesn't matter, Mort is agile.  His values are agile.  He is paid to be agile.  He delivers value quickly, with large amounts of interaction with the customer, not a lot of process, and not a lot of documentation.  According to the Agile Manifesto, in a specific situation, Mort is agile.  He is also dangerous. 

    So we constrain him.  As long as Mort can't hurt himself and others, we are protected from him. 

    Of course, we can give Mort smarter tools.  But that goes back to the argument that Mort is the problem.  Mort is not the problem.  His employer is.  We train Mort.  He becomes a quality programmer.  He leaves. The company hires another Mort.

    So what about those Morts that we cannot train?  Every time we try to shove great tools at "untrainable Mort", we don't get "smarter Mort."  The tools get used by other people, but Mort ignores them.  We get faster and better code written by the people who care about faster and better code.  Mort doesn't care.  He is not paid to care.  He is paid to write code quickly, solve a quick problem, and go on.  His code is not maintainable, and THAT IS OK, because he can write small amounts of code (or no code) and still deliver value.

    So how do we pull this off?  How do we allow Mort to write small amounts of code so that we don't care?

    We've been trying to solve this problem for a decade or so.  We tried creating an easy drag-and-drop environment, but it didn't protect us from Mort.  We tried creating controls that do all the hard stuff, but it didn't protect us from Mort. 

    Now, SOA and the Web 2.0 space has opened up a whole new world for Mort to play in.  Generation Next is here, and finally we may be a bit closer to an answer.

    Possible Answer: We can have Mort consume a service.  He can't change it.  He can't screw it up.  But he can still deliver value, because often 60% of the business value is in supporting individual steps in a business process.  Those steps are carefully controlled by the business, but honestly, are not that hard to put together.  It's a matter of "step one comes first, step two comes next."  As long as the details of the interaction are hard to screw up, we are protected from Mort. 

    Here's the cool thing: Microsoft didn't invent this iteration.  This little bit of "Mort defense" came from the integration space (think ESB) combined with great thinking from the web community.  This approach is not something we thought of, but it works to the same ends.  This new way is based on SOA principles and REST protocols (what some are calling WOA or Web Oriented Architecture). 

    Web 2.0 and Mashups are the new agility.  Write little or no code... deliver value right away.

    And in this space, Mort is agile.  Heck, we even like him.

    And in case you are wondering why I don't hate Mort... this is the space I live in.

  • Inside Architecture

    Creating a distinction between business services and SOA services

    • 28 Comments

    I'm always a bit dismayed when I hear the following terms mixed up, or combined: SOA service and business service.  In my mind, these things are different.  In one sense, they are related, but indirectly.

    A business service is a function (or capability) of the business that is offered to one or more customers.  Those customers are often  internal, because this scenario is often applied to corporate supporting functions. For example, the accounting business unit may provide "accounts payable" services to every business division of an enterprise.  Those divisions are internal customers.  The business unit is accounting, and the business service is "accounts payable."

    In some cases, the customers of the function may be both internal and external.  Many years ago, the Carlson company took their marketing division and not only made it into a shared function, that their various internal divisions could use,  but that division was able to offer their services to the general market as well.  They provide a list of shared business services used by both internal and external customers.

    The people who use shared business functions are "businesspeople" of all stripes.  They have work to do, and a business service is simply a way to do it.   A shared business service includes responsibilities, and therefore people who are responsible.  It is a kind of "sub-business" that has customers, and processes, and capabilities, and information.  In many companies, IT is run as a shared business service, providing technology services to many areas of the business. 

    A SOA service is a different animal altogether.  Service Oriented Architecture (SOA) is an architectural style.  That means it is a set of software design patterns.  These patterns are united in their support of a basic set of principles.  The people who use SOA are people who write software.  (If you compose an application, even if it is simple to do, you are writing software.)

    The logical data model that encapsulates this concept is below.  This is a very tiny part of the data model derived from our traceability model, which allows us to recognize the interdependencies between business processes, applications, and business units.  At the top of the image you see business services.  SOA services are on the lower right.  (click the image to enlarge)

    A business unit may provide zero or more business services.  Not all of the capabilities required by a business unit may be involved in a business service. 

    SOA provides the ability to share features.  Those features may provide information, or calculations, or data manipulation.  They may also include the limited automation of some elements of a business process.  SOA services are provided by "installed software" (we use the term "application" many times for this entity... a different blog post someday...).

    Business-vs-SOA-Service

    (note: I updated the image about 12 hours after posting this blog, due to an error in the original image -ANM)

    The point of this post is to provide sufficient context to challenge the notion that SOA provides shared business services.  It does not.  SOA provides shared features that many business units call upon.  Those features are required by the business processes within those business units. 

    Note to responders: before you flame me, take the time to try to map your concepts to the diagram above.  You may find that if you look for your concepts, and not your words, that you are simply using different words than I am to refer to the same concepts.  Disagree with me about concepts and I'm interested.  Disagree with me because I don't use a word in the same way that you do, and we will probably not have a very interesting discussion.

  • Inside Architecture

    JaBoWS is the Enemy of Enterprise SOA

    • 25 Comments

    As a community, we have sat silently by as the pundits have sold products that fail to deliver on the promise of SOA.  We have watched, many of us in horror, as the goal of changing behavior, and changing infrastructure, has fallen victim to "yet another tool" to solve the same problem.

    Don't get me wrong.  I don't hate tools.  For one thing, there are some tools that support Enterprise SOA*.  Not many, but a few.  Those tools understand that Enterprise SOA is not about building one service after another, but building the right services, and building them in a manageable and non-overlapping way. 

    What I hate is the notion that SOA can be reduced to tools; that you can introduce a tool and suddenly all the bad (human) behavior stops.  I want to dispel that notion right now.

    image

    • If you take a group of well-meaning and intelligent engineers,
       
    • and you give them a process that looks like a normal software development process**, and you train them on it, and they believe that this process works...
       
    • and you add SOA...
       
    • you get JaBOWS (Just a Bunch of Web Services).

    I did not invent the term "JaBOWS."  Near as I can tell, Joe McKendrick did, a couple of years ago.  However, I am taking it one step further.  I believe that JaBOWS has specific causes and can be specifically avoided.  Not just with an executive sponsor, as Joe suggested back in 2005, but with a comprehensive Enterprise SOA transformational program, an approach designed to create a reusable infrastructure. 

    Failing that, companies that invest in SOA are getting tripe, and the entire goal of achieving Enterprise SOA takes a hit.  We all lose when any one company kills their SOA initiative for lack of value.  In the SOA community, we are all invested in the success of each company that has bought the hype.  If we sit quiet, well before those initiatives fail, then we have no right to come back, two years from now, and say "well, it failed because you didn't do it right."  Or worse, "if you do it again, we can show you how to get value."  That Ain't Gonna Happen.

    As a community, we have to do a better job of defining what it means to build an Enterprise SOA*. 

    In Microsoft IT, we are using something we call "Solution Domain Architecture" or "SDA" to build an approach to services that, we hope, will result in the creation of an Enterprise SOA.  SOA is the benefit, SDA is the way to get there.  And the reason to use SDA: to avoid JaBOWS.

    In order to force that growth, and leave the bad behavior behind, we have to declare war on JaBOWS. 

    JaBOWS is the dead end that kills value.  It is all that is wrong with top-down approaches that produce unusable services, or bottom-up approaches that produce overlapping and badly coordinated piles of services.  JaBOWS is the costly, time-consuming, valueless exercise that so many companies have taken upon themselves in the name of SOA. 

    Join me now.  Join me in decrying the creation of piles of useless and valueless noise.  It doesn't matter if it can be discovered, or governed, or built quickly, if it is not reusable.  It doesn't matter if it is built on WS* or leverages the best security protocol on the planet, if it is not decoupled correctly. 

    Join me by writing about JaBOWS, and talking about JaBOWS, and sharing experiences about how to effectively avoid JaBOWS.  Join me by sharing what is wrong with building too many things, none of which are actually usable outside their original context.  Join me, by discussing the processes by which developers build the right systems, not just the tools that we need to buy and the interface standard we need to adapt.  None of those solve the problem.

    It's not a tools problem.  It is a process and people problem.

    Tools + existing processes = JaBOWS.   And that is baaaaaad.

     

    * Enterprise SOA goes way beyond "making two apps talk using a web service interface."  It is a systematic approach to developing an Enterprise-wide Service Oriented Architecture that actually allows information, process, and functionality to be composed in new ways, ones that were not foreseen by the authors of the services.  Until you have this, Web Services are just "interoperable COM."    Without Enterprise SOA, you have JaBOWS.

     

    ** I am including agile development here.  There is nothing in Agile methods that makes the problem worse, but there is nothing that makes the problem better, either.  If you say there is, tell me what agile book, on what page, aligns the agile manifesto with Enterprise SOA development.  I have all the books right here. 

  • Inside Architecture

    Put a ruler to the blueprint... is it useful?

    • 25 Comments

    My favorite posession in high school was my drafting board.  Yep... I was geek, even then.  I was going to be the next Frank Lloyd Wright (or at least, I wanted to die trying).  I fell in love with Architecture in a high-school drafting class and was hooked.  I had notebook after notebook filled with sketches of floor plans and perspective drawings.  The year was 1979.  Good times.

    So when I was talking to a fellow architect recently about one of our team meetings, I realized that I had a good thing back then, something that I don't have today in my current incarnation of 'Architect.'  When I created a set of blueprints for a house, it was accurate.  I was a careful person because I had to be. 

    You see, the goal of a blueprint is that I can give a package of drawings to a builder and literally walk away.  The house that he or she builds should (if I did my job well) come out looking A LOT like the picture on the paper.  Not identical, mind you.  There will be minor gaps, and the builder may have to make a compromise or two, but for the most part, I should be able to walk through the finished house and find everything pretty much where I put it on paper.

    If the builder had a question about the amount of carpet to order for a room, for instance, they could whip out a ruler and measure the size of the room on the blueprint.  If the scale was 1/2", and the room, on paper, measured out to 6 inches wide, the builder KNEW he could order 12 feet of carpet.  (Of course, he would order 13 feet... just in case).

    Point is that the diagram was so accurate that the builder would not have to ask me for anything that he could get by whipping out a ruler and measuring the drawing on the paper.

    Why don't we have this kind of accuracy in our architectural models? 

    Is that something we should strive for?  This is not an MDA question.  This is an accuracy question. 

    In your opinion, gentle reader, what level of accuracy should the architectural model go to?

  • Inside Architecture

    Are Helper Classes Evil?

    • 25 Comments

    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

    Free Code - Getting IT out of the Applications business

    • 22 Comments

    There is one big thing we must do if we are to make IT align with business strategy, we need to get IT out of the role of interpreting the whims and desires of the business.  The good folks in IT are really bad at mind-reading.  As long as we are in the "mind-reading" business, we will never be given credit for what we do well: automation.

    The answer: let the business folks write free code.  Not just any business folks.  We let Business Process Developers write free code.

    What is free code?  Free code is unmaintainable code that wires together service calls in a way that is inexpensive to produce.  Free code is mashup code.  Bugs can be fixed, but we don't really maintain it.  If we want to change free code, we write it again.  It was so inexpensive to build that it costs less to rewrite than to modify in any non-trivial way.

    Free code, in order to be truly free, needs to be generated from tools that are NOT coding tools.  In other words, software development environments are too rich for free code.  Why?  Because it is too tempting to build expensive code.   We need to differentiate, then, between the rich, highly designed, object oriented code that software developers produce, and the free code that business process developers will produce.

    Note: I said that free code is unmaintainable.  Code is unmaintainable because it's complexity exceeds the ability of a developer to maintain it. Let's dig a little deeper.  Why do we need to maintain code?  Because code is expensive to write.  Therefore, it is currently cheaper to fix it than rewrite it.  On the other hand, what if code were cheap, or free?  What if it were cheaper to write it than maintain it? 

     Then we would never maintain it.  We'd write it from scratch every time. 

    Sure, we can choose to write maintainable code.  We can use practices like patterns, object oriented development, and careful design principles.  On the other hand, we can give our business project managers an environment where they can describe their needs and code is simply expressed from those needs.  If the code that comes out doesn't meet their needs, the business process developer knows it the moment they run their code. 

    What is the value of doing this?

    1) Lower the cost of IT through reduced skill requirements.  The skill set of the Business Process Developer is different from that of a software developer.  Traditionally, we've sought folks with both skill sets to employ as software analysts.  This usually meant training someone.  What is wrong wit that?  Answer: We've created expensive specialists to overcome tool deficiencies.  Why not fix the tools?  Then we won't need the specialists that cost so darn much.

    2) The speed of development goes up.  If the business process developer can change the process wiring readily, then the software developer can focus on making the needed updates to the services themselves.  This removes the coupling between process and code that slows down EVERY project in IT.   

    3) Projects become more agile.  Since a business process developer can develop a mashup of services quickly, they can demonstrate that mashup very readily, directly to business stakeholders.  A change can be shown to the business folks quickly as well.  If the business needs change, or their understanding grows, and they need the services to do something more than they do, then this kind of agile process encourages rapid feedback to the developers who own the services themselves. 

    4) Solution quality goes up.  Since we can focus our deep design team on developing the services that the business process developers consume, we can improve the quality of those services independently.  This allows for better measurement of quality and an increased focus on the key quality measures inside each service.  Reusability is a natural outcome of high quality services.

    What does this mean for our tools:

    We need to seperate business process modeling from software development and produce rich tools aimed at the needs of the BPM practitioner.  Those tools need to start and end with an understanding of business capabilities, tied through to business processes, and down to events and business documents against a common information model. 

    We need our tools to reduce the leaky abstractions that we currently call 'services' by helping developers build services that are very simple to consume by the business process developers.  We need to capture these requirements and act on them through automated mechanisms built in to both the BPM environment and the IDE.

    What does this mean for our processes:

    The good folks in IT need to formally and officially take control of managing the common enterprise information model and the business event ontology.  If a business wants to change the data and event models, they need to work through a published process that allows and encourages consensus. 

    The good folks in IT need to formally allow business process developers to easily develop, test, and deploy their processes.  Deployment is a problem because IT folks normally just 'fudge' their way through deployment processes.  If we are going to let business process folks to write code that we deploy, then it needs to be very simple to deploy that code.

    Free code makes sense...  We need to align IT to business, and this is one very useful mechanism to do it.  It is time to stop getting in each other's hair.

Page 1 of 106 (636 items) 12345»