Slashdot Mirror
IEEE Guides Software Architects Toward Secure Design
msm1267 writes: The IEEE's Center for Secure Design debuted its first report this week, a guidance for software architects called "Avoiding the Top 10 Software Security Design Flaws." Developing guidance for architects rather than developers was a conscious effort the group made in order to steer the conversation around software security away from exclusively talking about finding bugs toward design-level failures that lead to exploitable security vulnerabilities. The document spells out the 10 common design flaws in a straightforward manner, each with a lengthy explainer of inherent weaknesses in each area and how software designers and architects should take these potential pitfalls into consideration.
I don't have a lot of patience with the profession since it's built on a fatally flawed analogy and all software architects ever do is waste and overhead from a lean perspective.
Your article written on the flaws in the software architect analogy is a good read, but the role of software architect I am used to seems to be far different than the one you are referring to. When I think of a software or systems architect, I am not thinking of someone who is writing or usually even designing software. They are more often determining how different software systems and business processes are interacting with each other. In most situations, each of these software systems is a black box to the architect. The only software code the architect is usually responsible for is any custom middle-ware products needed to help each system interface with each other.
In this context, many of the critiques you mentioned in your 2003 article are not as valid. Systems architectures are not easily duplicated for different companies, just like a building cannot be easily duplicated. And when working with software products that are often black boxes, the software architect will likely be just as constrained as a construction architect (although usually not by as many regulations and codes).
Obviously there are strong differences between the fields, but there are strong differences between mechanical / electrical / chemical engineers as well. And just as the word engineer has evolved from someone who builds medieval machines of war, I personally see no problem with the word architect evolving from just someone who designs and supervises the construction of buildings.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
I don't have a lot of patience with the profession since it's built on a fatally flawed analogy and all software architects ever do is waste and overhead from a lean perspective.
It *sounds* like you've never worked on a large project then. Fine, fire the architects, but you're still going to need someone to do their job, no matter if you call them the team lead or something else. There needs to be a *technical* person at the top who says "we're marching that way" and here's some stuff we need to keep in mind and do. Some technical person who can push back to the product owner when it's needed and explain in technical gory details when required. That's not the project manager because they're not technical enough; or that's been true for all the projects I've ever worked on.
... the cheapest time to change software is during the planning stage before it's written.
You need someone to can look ahead at the items coming and notice that there are some common things needed, and that if you spend some time up front to fix (a framework, a subsystem, whatever) that it will be cheaper and faster to do that way than to let small bits of code be written and then refactored a hundred times as the sprints slowly come in.
I'm sorry you don't like the construction analogy, but it's very true that the cheapest time to change a building is when you're still at the blueprint stage before it's built
Sure, most product owners owners don't really know where they want to end up, but some things are well known and when you have that knowledge you should use it as soon as possible, no matter what you want to call the roles or the results. Protocols, APIs, security, data models and databases, etc are all things that should be planned as much as possible, not organically grown and refactored. Who does that planning?
My day job right now is dealing with code that had very little upfront planning, very Agile'ish, and the system is a nightmare at times. I'll admit that the source of the problem may be that the devs before me never came back and refactored and cleaned up, but a little more planning would have made much of that unnecessary. That's what an architect brings to the table: some overall planning and technical sense.