Test yourself: 25 most dangerous security programming errors

By |2009-05-31T15:04:44+00:00May 31st, 2009|Enterprise Architecture|

The SANS institute has published a list of the top 25 most dangerous programming errors.  Not only is this a must-read, but it is critical for architects, developers and testers, of all stripes, to be aware of these programming errors.  Unless and until we have platforms that simply prevent these errors, we can combat these security gaps best through education, careful testing, and responsible project delivery practices.

http://www.sans.org/top25errors/

How familiar are you with these mistakes? 

Would you be able to spot them in code you reviewed? 

Would you be able to prevent them in your own code? 

Why “good” doesn’t happen

By |2009-05-30T11:30:19+00:00May 30th, 2009|Enterprise Architecture|

On a blog post titled “what good looks like,” Alan Inglis detailed a list of “project architectectural artifacts” that he wishes that previous architects would leave behind when a project is completed. 

In his list, Alan details 10 artifacts (actually 14, if you use the ZF to catalog them) that he’d suggest should be created.  His advice is interesting, but there is a flaw in the logic.  I’ll examine his suggestion from a couple of viewpoints, to illustrate why I believe that his advice is incomplete, and to offer a suggestion for completing it.

Context

It is normal, when we begin a project, to detail out the things that we wish we had.  Therefore, we “should” create them for the next person.  Viewpoint 1: at the beginning, looking forward, defining project requirements. 

It is also typical to open up a maintenance project and need to make changes, only to find yourself wondering about the choices made by the person before you.  Viewpoint 2: in the middle, looking back, trying to understand.  (In my past dev teams, we called this process an “archeology expedition.”)

The problem with his list of artifacts (which is quite comprehensive) is that “wishing” does not constitute a requirement.  If I create an artifact “for the future” that does not mean that the people, in viewpoint 2, will use it. 

Unless there is a built-in development process that REQUIRES architects and developers to visit a repository, and withdraw relevant documents, then you have no business justification for performing the task.

I question every requirement that has no business justification, especially if it is not tied to a business process.  This is easily fixed: tie the documentation ‘requirement’ to a business process… the process of designing architecture.

Suggestion

People in “viewpoint 2” should have the requirement of looking things up, in a specific place, for a specific reason.  We need to carefully describe the processes around this “learning” phase.  Why would we look things up?  What things would we look up, and most importantly, what are the triggers or scenarios in which a lookup process is required?

Let’s draw the requirements for documentation from that development process… not from a wish list

For example: If I believe that it will be useful to create a list of terms (glossary), let’s understand the scenarios where a list of terms would be useful. 

  • Would it be on THIS application, or any application tied to the same business unit
  • What do I need to know about a term? 
  • If I look up a term, would it be natural to link that term to the conceptual data model (if applicable)? 
  • What about changes in the meaning or use of the term over time? 
  • If a term has changed, or an older term is no longer used, what guidelines must be followed to update that glossary? 
  • Should we keep older definitions, so that people inspecting older code can understand the code? 
  • Should we leave advice to those poor souls for how to interpret an older term in the context of a newer practice or process? 
  • Assuming many projects would use the same glossary, should we tie each term to the project or app that needed it?  (That way, a term won’t be deleted if a system that needs it is still running in production).

Discussion

I picked on the glossary, but EVERY ONE of the artifacts that Alan lists would have this problem.  Each describes some tiny part of a much larger ecosystem of information.  The moment the project goes into production, the artifacts must take their place among the hundreds of other relevant documents, from every other project.  They need to be findable, consistent, and AUTOMATICALLY linked together in a way that minimizes the “archeology expedition” that “viewpoint 2” implies.

This is no longer a “project” problem.  This is an enterprise problem.  The data describes part of the architecture of the enterprise, and as such, needs to be maintained at the enterprise level, for the sake of engineering. 

As Leo de Sousa pointed out in his reply to the Alan’s post, a repository is required.  But it won’t be a simple one, where we drop documents.  No, it will be a complex thing, that understands what each architectural element is, and how to find it, and how to link it to other elements, so that the artifact of the present doesn’t become the archeology of the future.

Make IT appear as simple as possible, but not simpler

By |2009-05-22T20:22:52+00:00May 22nd, 2009|Enterprise Architecture|

Sometimes I hear a complaint from an IT architect who wants to have direct conversations with “the business” or “the customer” but, for some reason (usually bureaucratic), they cannot.  There is a team of analysts or project managers that they are supposed to talk to. 

The original objective of having “layers” of people is to make IT appear simple.  We all agree that business constituents can become confused if they are dealing with a long list of people from IT, each of which have different concerns.  In the worst case scenario, a business user reaches out to an analyst to tell them about a software error, and the ‘problem’ gets handed off from person to person, adding time and confusing the user.

Many companies favor the “Single Point of Contact” approach. For each business unit, there is a single point of contact for all projects.  There may still be one more point of contact for “support” related concerns.  But that is all.  This hides some of the complexity from the business customer, but adds a layer between IT and the customer.

image

So where does the IT architect fit?  Does it depend on the type of architect?  Does the enterprise architect need to have direct conversations with business stakeholders? 

What about solution or platform architects?  Should they be talking “directly to the business?” 

It would seem obvious that business architects should, but how do business architects relate to business analysts?  There’s still the support side as well.  Does each application have their own support contact?  What happens when one application has the right data, and the next one over has the wrong data… who should the customer call?

So we have a problem.  That much is clear.  How to solve it?

I’d like to consider introducing a concept into the conversation: interdisciplinary teams.

The notion of an interdisciplinary team is not widely used in computing, but there are many examples in science.  Used widely in research, medicine, and public policy, interdisciplinary teams provide a way for specialists in many fields to work together to solve a problem.  Any problem can be addressed from many viewpoints, using an understanding that emerges from the unique combination of talent and responsibilities.

Many of the processes for collecting and describing requirements, including the well-understood “Joint Application Development” or JAD process, incorporate the same basic ideas, but do so in a less structured manner and only for a single “problem” (understanding requirements). 

What I’d like to see done is to use the concept more consistently.  For Information Technology, and for consulting, this is quite doable.  Instead of having a single person represent IT to the business, have a team of people.  They meet the business on a monthly basis, and the concerns of each of the people can be brought to the monthly meeting.  All of this is coordinated by a single “IT Engagement Manager” or “IT Relationship Owner.”  However, unlike the bureaucratic processes we see in some companies, there are a few rules that apply.

The interdisciplinary team will have predefined roles.  The list of roles cannot be reduced by either the IT engagement manager or business stakeholder.  One person can fill more than one role.  However, the IT engagement manager does not assign IT staff to those roles.  That is up to IT leadership to do.

This kind of interdisciplinary structure can allow a more direct flow of information, communication, and shared commitments than is possible with the “single point of contact” model.  At the same time, the business stakeholders don’t get randomized by multiple requests for the same information or by the miscommunication that comes from collecting different information at different times in different contexts to apply to the same problem.

In many ways, using a single point of contact is an attempt to make the relationship, between IT and the business, simple.  It is too simple… to the point of ineffectiveness.  I believe that a broader approach is often a better one.

Architecture makes Agile Processes Scalable

By |2016-09-28T22:41:37+00:00May 19th, 2009|Enterprise Architecture|

As many of you may know, Microsoft has a vocal and thriving Agile Software Development community.  Recently, on our community forum, a question appeared about the ability of Agile development to “scale” to a large team.  In other words, if we can make agile development practices work in a dev group with hundreds of people, can we make it work in a dev group with thousands of people?

There was a lot of discussion on the alias.  Much focused on process improvements.  E.g. how to create scrum of scrums, and how to automate test and build processes so that large systems can be integrated continuously.  That is part of the answer.

However one quote, from a seasoned and experienced engineering leader, Nathan McCoy, who joined Microsoft as part of our acquisition of aQuantive , provides a real clue to the rest of the answer.

The answer is yes, agile can scale to larger systems…  Here’s the quote: (more…)

Are we ready to prove the “Architecture hypothesis?”

By |2009-05-13T12:56:33+00:00May 13th, 2009|Enterprise Architecture|

Science progresses on the willingness to take widely held beliefs and test them.  It is one thing to say that a medicine will “cure all that ails ye” but it is another thing altogether to prove that a particular medicine will have a particular effect on health.  Proof is expensive, but science does not march forward without it.

For quite a while, our team has been working diligently to increase the use of architectural models (and architectural thinking) among our IT units.  There are thousands of employees engaged in developing software in MSIT, and it is not always easy to reach a wide audience and make a compelling case.  Our arguments have been based on appeals to logic (clearly, it works), metaphor (it works in other areas of engineering) and anecdotal evidence (it worked on project Foo and see the benefits they got). 

But at the end of the day, we have not been using science.  We never ran a true scientific study to demonstrate that the use of a particular architectural practice improved the outcome of software engineering in a specific and measurable way, compared to a project that did not use architecture.

I’d like to see us, as an industry, get to the point where we can perform a scientific experiment on the efficacy of using software architecture practices to improve software development outcomes.

We’d need a protocol for the experiment, and controlled variables, to reproduce the effects of using architecture.  We’d need a specific definition of what it means to “use architecture” and the specific practices that we believe will have an impact on outcomes.  We’d need a clear way to measure the outcome of the experiment so that, when repeated, anywhere in the world, the experiment could produce comparable results. 

And here’s the rub: I’d like to see it be something that YOU can help with.  The community of architects and developers that care about things like SOA, Architecture, and Planning… we are the people who can perform the experiment in 1,000 settings around the world.  We are the ones that can prove, or disprove, the hypothesis of software architecture.

If anyone has experience with this kind of experiment, I’d love to hear from you, just to see if this idea is too difficult for the community to do.  Personally, I’m not sure where to start.  If you have ideas, please reach out to me.

The Process of Strategic Planning

By |2009-05-07T13:41:00+00:00May 7th, 2009|Enterprise Architecture|

I’m a process guy.  I’m not a big fan of the claims of process management software, but I’m a huge fan of developing and using process models to organize the activities of people, and then to drive the requirements for software from those models.

So when I was asked to look into the processes for Strategic Planning (one of the three business functions of enterprise architecture), I took a process oriented approach.  I looked at each of the different activities that have been suggested or planned or were being performed in strategic planning.  I created a chart of inputs and outputs and linked it up so that the output of one activity is the input to another.  Normal stuff. 

Without going into the details of the result, I would like the share the huge reliance that all of the activities have on a basic understanding of what the business is and does.  It became obvious when we began to trace back the core element of strategic planning: the business goal.

Strategies chart a path to a business goal.  Both the OMG Business Motivation Model, and my Enterprise Business Motivation Model, say this same thing.  A strategy is a statement of “how” a business can reach a goal.  But beneath this statement, we have to recognize something even more fundamental: that an enterprise can have more than one business.

Let’s say that your company is a clothing retailer.  If you are successful at all, you probably have one or more “lines” of clothing that are made for you, and sold only through your stores.  That is differentiation.  You also may have clothing that is made by a well-known manufacturer and is sold widely, including in the stores of your competitors.  (this applies to other products, not just clothing, but I’ll stick with the scenario for now).

How many businesses are you in?  If we want to look at the strategies of your business, it matters.  This is because the strategies that may make the “custom made clothing” business successful may actually work against the “name brand retailing” business.  A strategy to promote the in-house brands may hurt relationships, or drain resources, or drive down prices of the name brand products. 

So before you can even write down a strategy, you have to write down the number of businesses that you are in, and then, when you write down the strategy, you write it down in context.  You say “this is a strategy for making Business 2 meet it’s goals.”  You may not know if that strategy hurts “Business 1.”  Depending on the organization of the business, and your responsibilities within it, you may not actually care. 

But the business architect must care.  The business architect, in this example, must be able to say “you are in two businesses, and they sometimes compete for resources, customers, and market-share.”

So as you look at your strategic planning processes, don’t forget to take the time to chart out how many businesses you are dealing with.  It is such an important part of the “first step” to strategic planning.

ouch

By |2009-05-05T19:30:00+00:00May 5th, 2009|Enterprise Architecture|

I started two good blog posts today.  Both will wait for another day, as I take this space to say goodbye to three colleagues friends  from my department who were laid off today.

Gentlemen, I am sorry to see you go.  I consider myself blessed  to have had the opportunity to work with such talented, intelligent, and gracious individuals.  We worked on some great projects together, and from each of you, I’ve learned many things.  Please stay in touch and let me know where you land. 

To my readers, I’ll wax philosophic another day.  Today, I cannot.

[update: 7-May-09  I’ve just been informed of the layoffs of three more friends in other teams.  One name is familiar to the blogosphere.  The others were simply excellent employees. 

I cannot say that this process has been anything less than personally painful.]

To all those who have lost their jobs, in Microsoft and every other business or organization this past half year, I send this famous Irish saying:

“May the road rise to meet you,
May the wind be always at your back,
May the sun shine warm upon your face,
The rains fall soft upon your fields,
And until we meet again,
May God hold you
In the palm of his hand.”

B’hatzlacha – Good Luck