The Artima Developer Community
Sponsored Link

Weblogs Forum
Software Architecture is Leadership

18 replies on 2 pages. Most recent reply: Apr 8, 2006 12:47 AM by David Chazin

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 18 replies on 2 pages [ 1 2 | » ]
Bill Venners

Posts: 2248
Nickname: bv
Registered: Jan, 2002

Software Architecture is Leadership (View in Weblogs)
Posted: Apr 4, 2006 12:22 PM
Reply to this message Reply
Summary
A software architecture should not only explain how things are done in a software project, it should guide the team in that direction.
Advertisement

In a recent developerWorks article, What is a software architecture?, Peter Eeles attempts to capture a definition for the elusive notion of software architecture. Some of the more illuminating portions of this article for me were:

[An architecture] is only concerned with those elements that are deemed to be significant. Significant elements are those that have a long and lasting effect, such as the major structural elements, those elements associated with essential behavior, and those elements that address significant qualities such as reliability and scalability. ... Architectural significance can also be phrased as economical significance, since the primary driver for considering certain elements over others is the cost of creation and cost of change.

Here I felt he captured the idea that the architecture is an abstraction, a high-level view, of the system. It focuses on aspects of the system that are most helpful in accomplishing major goals for the system such as reliability, scalability, and changeability. The architecture explains how you go about accomplishing those goals.

Eerles also pointed out that a system's ability to incorporate change over time is a measure of the goodness of the architecture:

It is also worth noting that the set of significant elements is not static and may change over time. As a consequence of requirements being refined, risks identified, executable software built, and lessons learned, the set of significant elements may change. However, the relative stability of the architecture in the face of change is, to some extent, the sign of a good architecture...

These portions of Peter Eerles article reminded me of the ideas of Luke Hohmann, who, when asked in an interview, "What is architecture?", said:

That's like asking, what is culture? Culture is the way you do things in a group of people. Architecture is the way you do things in a software product. You could argue by analogy, then, that architecture is to a software product as culture is to a team. It is how that team has established and chosen its conventions.

Which leads us inevitably to the question of "goodness". How do you know if an architecture is good? Consider an architecture that isn't built using a strong domain model, and instead relies heavily on stored procedures. That might be OK, or it might not be OK. You could have decided that part of your architecture is to use a really strong domain model and not use stored procedures, right? So an architecture is some reasonable regularity about the structure of the system, the way the team goes about building its software, and how the software responds and adapts to its own environment. How well the architecture responds and adapts, and how well it goes through that construction process, is a measure of whether that architecture is any good.

What's important about software architecture?

I think one of the most important ways to think about architecture is that it is an opportunity to provide leadership. The architecture embodies the decisions of the architects, the leaders, on how things should be done in the project. The architecture should make it easy for people working on the project to do things the right way: the way the architects believe things should be done. In other words, instead of just saying that things should be done a certain way, the architects should design architectural systems and structures that guide the team down that path.

For example, we have made a lot of decisions about how we'll do things in our new architecture at Artima, and we recently captured many of those decisions in some code generators. So instead of just decreeing that entities can be versionable, and that versionable entities will have deletion and history tables that follow certain conventions, we made it so easy to do things that way, that no one will ever be tempted to do it any other way. All you need to do is add the word "versionable" in front of "entity" in the DSL we created for defining entities. The generated code will always follow the conventions exactly.

In other words, not only can the architecture explain the way the team does things in a software project, it should guide the them to do things that way.


Luis Sergio Oliveira

Posts: 22
Nickname: euluis
Registered: Jan, 2004

Re: Software Architecture is Leadership Posted: Apr 4, 2006 6:28 PM
Reply to this message Reply
I have worked in projects where architecture was a main focus and I agree with your post about the Architecture showing the way things are done. Its very good working in such projects. It makes us feel secure about design decisions not breaking the overall product Architectural consistency. Its also many less things to worry or think about and developers will more easily focus in their tasks.

Regarding code generation enabling ease of implementing things according to the architectural decisions, I think that other way is to use Aspect oriented validations of interactions between the software system parts.

Yet another way is to provide Architects' developed utility libraries that facilitate using 3rd party libraries or performing some common task the "correct way". Sure this must be followed by an example of their use for a specific component...

Bill Venners

Posts: 2248
Nickname: bv
Registered: Jan, 2002

Re: Software Architecture is Leadership Posted: Apr 4, 2006 8:15 PM
Reply to this message Reply
> Regarding code generation enabling ease of implementing
> things according to the architectural decisions, I think
> that other way is to use Aspect oriented validations of
> interactions between the software system parts.
>
I've been wanting to get more familiar with the existing AOP tools for Java, to see how we might be able to apply them. How would you use AOP to validate interactions between the software system parts?

Luis Sergio Oliveira

Posts: 22
Nickname: euluis
Registered: Jan, 2004

Aspect Oriented validation of architectural decisions Posted: Apr 5, 2006 3:06 AM
Reply to this message Reply
> > Regarding code generation enabling ease of implementing
> > things according to the architectural decisions, I
> think
> > that other way is to use Aspect oriented validations of
> > interactions between the software system parts.
> >
> I've been wanting to get more familiar with the existing
> AOP tools for Java, to see how we might be able to apply
> them. How would you use AOP to validate interactions
> between the software system parts?

With AspectJ for instance its possible to setup static code analysis and create a compilation error if a method's class within a specific package (or a package which name matches a certain criteria) is called from another package.

Thus it enables you to, e.g., prevent dependencies such as DAO packages to access service facade classes. I'm not so experienced with this to provide example code just out of my head, but, I know its possible.

Off coure I think this kind of thing is possible in runtime for other Aspect toolkits...

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Aspect Oriented validation of architectural decisions Posted: Apr 5, 2006 10:17 AM
Reply to this message Reply
> With AspectJ for instance its possible to setup static
> code analysis and create a compilation error if a method's
> class within a specific package (or a package which name
> matches a certain criteria) is called from another
> package.
>
> Thus it enables you to, e.g., prevent dependencies such as
> DAO packages to access service facade classes. I'm not so
> experienced with this to provide example code just out of
> my head, but, I know its possible.
>
> Off coure I think this kind of thing is possible in
> runtime for other Aspect toolkits...

It seems to me that you could accomplish this (in Java) with dependency checks in an Ant build or other build tool. I don't see a need for this at runtime.

Bill Venners

Posts: 2248
Nickname: bv
Registered: Jan, 2002

Re: Aspect Oriented validation of architectural decisions Posted: Apr 5, 2006 11:58 AM
Reply to this message Reply
> With AspectJ for instance its possible to setup static
> code analysis and create a compilation error if a method's
> class within a specific package (or a package which name
> matches a certain criteria) is called from another
> package.
>
> Thus it enables you to, e.g., prevent dependencies such as
> DAO packages to access service facade classes. I'm not so
> experienced with this to provide example code just out of
> my head, but, I know its possible.
>
> Off coure I think this kind of thing is possible in
> runtime for other Aspect toolkits...

I see. I think enforcing package layering is great, but it seems a bit overkill for AOP. There's a tool called Macker that I haven't tried yet that seems to be aimed at just such a problem:

http://innig.net/macker/

I also think it would be easy to write a Ruby script to do this kind of enforcing. Regardless of how you do it, I think it is a very good idea to integrate something into your build to enforce package layering rules that you have decided upon. We haven't done it yet, but I want to do it soon. (Just as soon as we get our packages perfectly layered.) Has anyone out there used Macker?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Aspect Oriented validation of architectural decisions Posted: Apr 5, 2006 12:41 PM
Reply to this message Reply
> I see. I think enforcing package layering is great, but it
> seems a bit overkill for AOP. There's a tool called Macker
> that I haven't tried yet that seems to be aimed at just
> such a problem:
>
> http://innig.net/macker/

Thanks for the pointer. Do you happen to know of a package that would produce some sort of recursive dependency report for an entity in Java code? Kind of like what Eclipse does when you 'search for references' but recursively.

Bill Venners

Posts: 2248
Nickname: bv
Registered: Jan, 2002

Re: Aspect Oriented validation of architectural decisions Posted: Apr 5, 2006 1:01 PM
Reply to this message Reply
> > I see. I think enforcing package layering is great, but
> it
> > seems a bit overkill for AOP. There's a tool called
> Macker
> > that I haven't tried yet that seems to be aimed at just
> > such a problem:
> >
> > http://innig.net/macker/
>
> Thanks for the pointer. Do you happen to know of a
> package that would produce some sort of recursive
> dependency report for an entity in Java code? Kind of
> like what Eclipse does when you 'search for references'
> but recursively.

There are a few open source dependency checkers listed here:

http://java-source.net/open-source/code-analyzers

I tried JDepend. It is an ant target in our build, but I haven't quite figured out what to do with the output yet. I wanted to get a nice graphical picture of dependencies, and it can do that, but I was unable to get it to prune things I didn't care about. So I kind of gave up and moved on.

We looked at ClassCycle and Dependence Finder too. We haven't gotten far enough to know if they will do what you are looking for. Why do you want the recursive report?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Aspect Oriented validation of architectural decisions Posted: Apr 5, 2006 1:47 PM
Reply to this message Reply
> We looked at ClassCycle and Dependence Finder too. We
> haven't gotten far enough to know if they will do what you
> are looking for. Why do you want the recursive report?

We have some old (read: crap e.g ~10000 line classes) code and when we need to change things, trying to track down what it might break takes many many times longer than the actual change. We end up having to do the recursive search just without the tool. Often we have to throw a hail Mary and hope testing shakes out any issues. We'd still need to do work because we have a lot of factories that load factory instances of classes from names in the DB which load instances of classes from names in the DB.

It would also help use figure out what code can be removed from our source and in estimating the cost of cleanups and for finding live code for rewrites.

Thanks again.

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Is architecture just 'big' design ? Posted: Apr 5, 2006 1:58 PM
Reply to this message Reply
I am always concerned that 'architecture' is only a grandiloquence for 'design'. There is nothing wrong with the distinction being only one of degree. But is there a more clear-cut one?

Jacobson seems to place architecture, somewhat implicitly, above matters of implementation (hardware, OS, language). That might be a reasonable point.

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

The inverse view... Posted: Apr 5, 2006 1:59 PM
Reply to this message Reply
It is interesting to consider things in reverse: The *flexible* parts of the architecture should match what the requirements *don't* specify. It is what the requirements miss that causes trouble. How to extract that 'shadow-space' is perhaps intriguing. Maybe some non-software, linguistic-social analysis/study... hmmm...

Luis Sergio Oliveira

Posts: 22
Nickname: euluis
Registered: Jan, 2004

Re: Aspect Oriented validation of architectural decisions Posted: Apr 5, 2006 4:57 PM
Reply to this message Reply
> > Thus it enables you to, e.g., prevent dependencies such
> as
> > DAO packages to access service facade classes. I'm not
> so
> > experienced with this to provide example code just out
> of
> > my head, but, I know its possible.
>
> I see. I think enforcing package layering is great, but it
> seems a bit overkill for AOP.
> (...)

I have to admit that I choose the easy example. Another is based on the utility libraries example. If you have a requirement to log all method calls between any two software components (e.g. EJB, MBeans, plugin, etc) and want to enforce specific conventions for this, like method name, arguments, time, etc, it fits nicelly to deliver this as an Aspect and have all components to be built with a task that autommatically and transparently provide this. Off course it could be done via code generation... [Maybe I felt into the easy example again...]

Oh! Policy enforcement at runtime: you have heavywheight queries on the database that want to keep bellow certain thresholds, so, you specify that this kind of queries should use iterator pattern. But, to enforce this you setup that runtime validation of this and that noone is having more than 1000 elements array being returned over the network. This kind of Architectural decision is hard to enforce, but, with Aspect oriented toolkits made by the Architecture team you can... It might be stripped out after QA tests.

So, I think this kind of thing isn't feasible using static analysis!

PS: I have seen this exact example in API documentation for n-tier system. But, without validation at runtime you just have good intentions.

Luis Sergio Oliveira

Posts: 22
Nickname: euluis
Registered: Jan, 2004

Re: The inverse view... Posted: Apr 5, 2006 5:03 PM
Reply to this message Reply
Hi, indeed, that's why agile practices matter. They help getting feedback early and help keeping Architecture something that changes or adapts. Also, better requirements gathering also helps... On this topic and others I'm currently learning a lot from Tyner Blain (http://tynerblain.com).

Bill Venners

Posts: 2248
Nickname: bv
Registered: Jan, 2002

Re: The inverse view... Posted: Apr 5, 2006 6:16 PM
Reply to this message Reply
> It is interesting to consider things in reverse: The
> *flexible* parts of the architecture should match what the
> requirements *don't* specify. It is what the requirements
> miss that causes trouble. How to extract that
> 'shadow-space' is perhaps intriguing. Maybe some
> non-software, linguistic-social analysis/study... hmmm...

The only way I can think to figure that out is having experience in the domain. And the only way to get it is to try something, get it out there, and then learn by pain which ways you should have made it flexible. You can also learn a lot from others, though. Enterprise architecture, for example, is something that has been experienced by a lot of people, and best practices written down and shared. But either way you are learning from experience, sometimes your experience, sometimes that of others.

Scala Enthusiast

Posts: 7
Nickname: sashao
Registered: Jun, 2005

Architecture _is_ a design Posted: Apr 6, 2006 3:53 AM
Reply to this message Reply
<rant>
>>> I am always concerned that 'architecture' is only a grandiloquence for 'design'. There is nothing wrong with the distinction being only one of degree. But is there a more clear-cut one? <<<

Exactly. In building they do just fine with architects but without designers. In fashion there are designers but no architects.

I can see 2 uses of the term "sofware architecture": 1) As a justification for salary raise to a competent engineer and 2) Being able to say "my design is bigger than yours" makes some people happy.

For that matter, is Ken Thompson an engineer, a designer or an architect? How about Linus Torvalds?
</rant>

Flat View: This topic has 18 replies on 2 pages [ 1  2 | » ]
Topic: The Thinking in Java Conference, July 18-21, 2006 Crested Butte, CO Previous Topic   Next Topic Topic: What's Wrong with Weblogs?


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us