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

    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.

  • Inside Architecture

    The non-overlapping responsibility set: Solution Architect and Enterprise Architect

    • 21 Comments

    Recently, Mike Walker posted a blog entry on the difference between Enterprise Architect and Solution Architect (sometimes called Application Architect).  I think this is an interesting space, because I believe that some folks have a mistaken perception that these two roles do the same things at different levels.  Nothing could be further from the truth, as Mike's breadth-depth diagram helps to illustrate. 

    The work of an Enterprise Architect is different from a Solution Architect, as different from each other as they are from Project Manager or Software Tester.  Certainly, a single person can play different roles over time.  A developer can become a project manager (or Scrummaster), but that doesn't mean that the job is the same.  

    Being an Enterprise Architect myself, who grew up out of Solution Architecture, I don't view the differentiation so much as a difference between breadth and depth, or the overlapping of roles, but rather as a partitioning of responsibilities.

    I think much of the misunderstanding about the role of the EA comes from a lack of visibility of the planning cycle for Information technology.  Many developers have no idea that a planning cycle even goes on.  (In some companies, the planning process is informal, or worse, hidden, so it is no surprise).

    image

    As Gabriel Morgan pointed out last fall, the activities of the Enterprise Architect fall mostly in the planning space, while the activities of the Solution Architect fall mostly in the Development space.  I indicate this with the "Span of Responsibility" triangles.  At any point in time, the thicker the triangle, the more responsibility that role has.

    To Be Clear: Planning does NOT include requirements gathering.  That is part of "Deliver." 

    Planning is about the organization deciding what projects to do, why to do them, what they should accomplish for the company, and how much should the company spend for them.  Planning decides to "build the right app."

    Delivery is the entire SDLC, including waterfall, agile, spiral, or some blended process.  Pick your poison.  The point is that the dividing line is the point where the organization decides to fund the project.  Only then are the requirements, use cases, scenarios, etc, collected.  All of our notions of object oriented development, and all the process debates, affect ONLY the "Deliver" slice.  Delivery decides to "build the app right."

    I believe that once a stakeholder understands this distinction, it becomes more clear to them what the Enterprise architect is responsible for.  The EA is not there to design an app, or figure out what the interfaces are.  They are there to make sure that all of the apps in the portfolio continue to be "about" building systems for the enterprise.  They insure that project managers keep integration interfaces in scope, because the app that will use that interface will be built next year... long after the current project is delivered.

    Enterprise architects take the long view.  No one else is paid to.

    [note: I updated the model on 10-Jun-08 to correct a mistake in the span of responsibility.]

Page 1 of 105 (628 items) 12345»