Some of the architectures look beautiful to me. I wonder what are some of the properties which make a Software Architecture beautiful and even if not beautiful ... very attractive. To be attractive something should be easily understood. Fewer concepts, fewer new concepts and simpler relationships between those concepts would constitute simplicity. If something is complicated you have to force your mind to understand it and chances are high that it will not appear beautiful unless the payoff of effort is higher. Later brings us to "surprise" aspect - core of Application Server like JBoss has nothing to do with applications or JEE, it is JMX, interested in only starting/stopping services.
Then something that brings a wow is, how much thinner the software can get. A big application server can have a microkernel only 50K size. That is beauty. For something flexible enough to grow very very big and shrink very very small, the core pattern has to be simple. And that pattern has to be repeatedly applied. And with zero exceptions. That catches attention.
And finally, recurrence. That always is attractive. The services of JBoss are MBeans loaded by core, but core itself is MBean. All this takes me to Mandelbrot ... aren't principles of what is beautiful same?
Showing posts with label Architecture. Show all posts
Showing posts with label Architecture. Show all posts
Tuesday, July 29, 2008
Saturday, April 26, 2008
Types of Architecture
Typically a big organization has multiple divisons/departments/businesses in it. There is a architecture applicable to organization as a whole to align the business strategy and IT investment. And then we have two more architectures, giving some more detail at each level. To me it looks like that it is intent and intended audience that decide what information goes into these architectures.
Enterprise Architecture could consist of four sub-architectures.
If you have some more hunger left for organizing the stuff a army of architects do at any company, read this interesting blog - Making sense of architecture standards.
Enterprise Architecture could consist of four sub-architectures.
If you have some more hunger left for organizing the stuff a army of architects do at any company, read this interesting blog - Making sense of architecture standards.
Tuesday, April 22, 2008
Architect defined by skills
Joseph Hofstader discusses the skills that Architect role demands - We Don’t Need No Architects.
There are four of them of categorized into two phases of software development - problem definition and solution development,
Problem Definition
There are four of them of categorized into two phases of software development - problem definition and solution development,
Problem Definition
- Domain - understand the domain well enough.
- Conceptual - is able to conceptualize and abstract.
- Technical - understands technology well and is always updated.
- Pattern - has rich pattern vocabulary, is able to apply them to design and use them to discuss intelligently the solution.
Architectural Styles and inspirations
The road of abstractions has infinite milestones. The infiniteness is a consequence of human thought, which finds patterns, commonalities, higher plane of unification at almost infinite levels. This writeup is about the abstractions as far as software architecture is concerned.
In "Architectural Styles and the Design of Network-based Software Architectures" thesis, author talks of Architectural Styles.
An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.
The styles are categorized into five categories,
1. Data-flow styles
However this is not the only abstraction. Lifetime Objectives and Lifetime design is another abstraction practiced by some. These are set of objectives and architectural concerns that are assumed to be true for entire lifetime of the architecture being created. Could we categorize architectures based on this? This is for a future writeup.
In many cases and mostly with me, the architecture comes with a simple underlying thought/strategy. A very simple statement that defines not the architecture but the direction of architecture. Let me call that as architectural inspiration. This is an overly simplified of universe in discourse, the domain world. Some of the architectural inspirations are, (replace world with everything)
1. World consists of objects. Objects have behavior and data.
2. World is made up of resources. Resources can be identified by URIs and accessed by a protocol.
3. World is only about services. Discover a service, use it and forget it.
4. World is a language. The language is understood by a platform and job of software development is to describe problem in the language.
In "Architectural Styles and the Design of Network-based Software Architectures" thesis, author talks of Architectural Styles.
An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.
The styles are categorized into five categories,
1. Data-flow styles
- a. Pipe and Filter (PF)
- b. Uniform Pipe and Filter (UPF)
- a. Replicated Repository (RR)
- b. Cache ($)
- a. Client-Server (CS)
- b. Layered System (LS) and Layered Client-Server (LCS)
- c. Client-Stateless-Server (CSS)
- d. Client-Cache-Stateless-Server (C$SS)
- e. Layered-Client-Cache-Stateless-Server (LC$SS)
- f. Remote Session (RS)
- g. Remote Data Access (RDA)
- a. Virtual Machine (VM)
- b. Remote Evaluation (REV)
- c. Code on Demand (COD)
- d. Layered-Code-on-Demand-Client-Cache-Stateless-Server (LCODC$SS)
- e. Mobile Agent (MA)
- a. Event-based Integration (EBI)
- b. C2
- c. Distributed Objects
- d. Brokered Distributed Objects
However this is not the only abstraction. Lifetime Objectives and Lifetime design is another abstraction practiced by some. These are set of objectives and architectural concerns that are assumed to be true for entire lifetime of the architecture being created. Could we categorize architectures based on this? This is for a future writeup.
In many cases and mostly with me, the architecture comes with a simple underlying thought/strategy. A very simple statement that defines not the architecture but the direction of architecture. Let me call that as architectural inspiration. This is an overly simplified of universe in discourse, the domain world. Some of the architectural inspirations are, (replace world with everything)
1. World consists of objects. Objects have behavior and data.
2. World is made up of resources. Resources can be identified by URIs and accessed by a protocol.
3. World is only about services. Discover a service, use it and forget it.
4. World is a language. The language is understood by a platform and job of software development is to describe problem in the language.
Monday, April 21, 2008
Selection over perfection
Many of us know that a complete solution (design/architecture) to a problem does not happen in one day. It takes months and years for a great architecture to be done. And what has hurt software engineering is to go extra mile for perfection. It is very interesting to take some ideas on ways to think or be creative from a poet - http://tesugen.com/archives/02/09/lowerstandards .
In the book Art & Fear by David Bayles and Ted Orland, is a story about a university pottery class that were broken into two halves: one half was told that their grades depended on the quality of a single pot handed in, while the other half should get their grades based on the total weight of all their semester’s pieces (50+ lbs was an A, 40-50 lbs a B, and so on).
The best pieces all came from the latter half of the group – the ones “graded by weight”. Blog uses this example to illustrate how a poet experienced a shift in his writing as he began to write one poem a day, instead of working on a single poem at a time, revising and polishing until it was good enough. Basially prefering a selection from his 100s of poems than perfecting few of them. Instead of making one long continuous mistake do once-a-day. Lower your standards and get things out - this way you are training your brain to be better each time you do a selection.
In the book Art & Fear by David Bayles and Ted Orland, is a story about a university pottery class that were broken into two halves: one half was told that their grades depended on the quality of a single pot handed in, while the other half should get their grades based on the total weight of all their semester’s pieces (50+ lbs was an A, 40-50 lbs a B, and so on).
The best pieces all came from the latter half of the group – the ones “graded by weight”. Blog uses this example to illustrate how a poet experienced a shift in his writing as he began to write one poem a day, instead of working on a single poem at a time, revising and polishing until it was good enough. Basially prefering a selection from his 100s of poems than perfecting few of them. Instead of making one long continuous mistake do once-a-day. Lower your standards and get things out - this way you are training your brain to be better each time you do a selection.
Sunday, April 20, 2008
Architect Oryzus - three pillars of architecture
Just read a very very interesting article - The Social/Psychological Side of Software Architecture (my talk at reboot7) (http://tesugen.com/archives/05/06/reboot7-talk). This article brings some more clarity on oryzus part of architect's role.
The author argues, there are three pillars of architecture,
1. Technology
2. Social
3. Psychological
The technology aspect is about describing the internal structure of software system.
The social properties of architecture are about making everybody get the same image of the architecture. Somewhere, filmmaker Francis Ford Coppola has said that the difference between a good and a bad movie, is getting everyone involved in making the same movie. Social aspects deal with memorability of how things work.
The psychological pillar is closely related to the social one. Where the social pillar of software architecture concerns architectures evoking similarly-organized mental pictures, the psychological pillar concerns architectures that stick in the minds of the individual team members. What becomes important is the process of getting to architecture that just the goal :architecture.
It is also interesting to know that buildings take on shape after they are built.
‘Porches fill in by stages, not all at once you know.’ The architect was responding to a talk I gave at a builder’s conference. ‘The family puts screens on the porch one summer because of the bugs. Then they see they could glass it in and make it part of the house. But it’s cold, so they add a duct from the furnace and some insulation, and now they realize they have to beef up the foundation and the roof. It happens that way because they can always visualize the next stage based on what’s already there.’
Author also talks of user and UI being an important part of architecture. In most of the definitions of architecture user word doesn't appear.
The author argues, there are three pillars of architecture,
1. Technology
2. Social
3. Psychological
The technology aspect is about describing the internal structure of software system.
The social properties of architecture are about making everybody get the same image of the architecture. Somewhere, filmmaker Francis Ford Coppola has said that the difference between a good and a bad movie, is getting everyone involved in making the same movie. Social aspects deal with memorability of how things work.
The psychological pillar is closely related to the social one. Where the social pillar of software architecture concerns architectures evoking similarly-organized mental pictures, the psychological pillar concerns architectures that stick in the minds of the individual team members. What becomes important is the process of getting to architecture that just the goal :architecture.
It is also interesting to know that buildings take on shape after they are built.
‘Porches fill in by stages, not all at once you know.’ The architect was responding to a talk I gave at a builder’s conference. ‘The family puts screens on the porch one summer because of the bugs. Then they see they could glass it in and make it part of the house. But it’s cold, so they add a duct from the furnace and some insulation, and now they realize they have to beef up the foundation and the roof. It happens that way because they can always visualize the next stage based on what’s already there.’
Author also talks of user and UI being an important part of architecture. In most of the definitions of architecture user word doesn't appear.
Tuesday, March 18, 2008
Less is More with Minimalistic Architecture
Read more here http://www.bredemeyer.com/pdf_files/MinimalistArchitecture.PDF
Architecture is equated to Control. More of it causes inefficiency. It should be enough to maintain focus.
Architecture is equated to Control. More of it causes inefficiency. It should be enough to maintain focus.
Architect Reloadus and Oryzus
Martin Fowler discusses two different types of Architects, http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
Architecture is decisons made that are important enough for everybody to know. This boils down to Scope-Impact model.
Reversability is another concept introduced there. Due to lack of reversability of certain decisons, these should be taken early on and are important enough to be part of architecture. The article argues that architect should try to avoid irreversability.
Architecture is decisons made that are important enough for everybody to know. This boils down to Scope-Impact model.
Reversability is another concept introduced there. Due to lack of reversability of certain decisons, these should be taken early on and are important enough to be part of architecture. The article argues that architect should try to avoid irreversability.
Friday, January 4, 2008
Recipe to prepare an Architect
This is how the job definition of Architect evolves. Multiple cooks in the organization add their own spice. The end looks like a recipe which has everything but taste. It is perfectly alright to assume that an aspiring Architect is an accomplished engineer. Then he/she should be able to technically look at any software from multiple levels -40,000 ft to ground level and should be able to do that effortlessly as an eagle would. And look forward in time.
Assuming all this is there, he/she should then have business acumen. To understand business and provide strategic inputs to it.
Between these two is a wide gamut of Leadership. He should be able to motivate technical people ... take the teams through different paths to reach the destination. He should be good at communicating the conceptualization, manage interests of all stakeholders.
But most of the architects are good in one or two of these areas. And to do justice to any one of these is itself a commendable task. Also, many times the company/product/situation demands only a subset of it. But the recipe is still open for someone to add new spice. Soon someone will end up listing enterpreneurship as key architect skill.
There is a need to divide Architect role into multiple levels and make the transition from an experienced engineer to architect little easier than it is. A quantum jump is not good for someone who has crossed it and someone who has given up crossing it.
Thursday, January 3, 2008
What is Architecture?
Architect is defined by Architecture
Architecture is defined by architect.
Architect owns architecture and whatever Architect creates is Architecture. Read more here,
http://www.bredemeyer.com/whatis.htm
This gives some vague idea about Architecture. It defines it as a set of very high level technical decisions which are systemic and have a high impact. So scope and impact are the two dimensions on which the first quadrant will be the archiectural concerns.
But there is one more dimension that some of the definitions revolve around - its the life of decisions. If the decisions live through the life of the product, most likely they will be architectural. This also means that these are decisons that are almost irreversible. Changing them is very difficult.
Architectural decisons are typically taken early in project lifecycle.
The above two points again tie into Scope-Impact model. Because of big scope and high impact the decisons are important enough to be taken early on. And the importance also guides the reversability.
Ofcourse each of these definition has exceptions. Once we have architecture, important thing is that Architect owns this. Own means - create, make changes and discard/replace at appropriate times.
Architecture is defined by architect.
Architect owns architecture and whatever Architect creates is Architecture. Read more here,
http://www.bredemeyer.com/whatis.htm
This gives some vague idea about Architecture. It defines it as a set of very high level technical decisions which are systemic and have a high impact. So scope and impact are the two dimensions on which the first quadrant will be the archiectural concerns.
Scope-Impact
S | | Architectural concerns
C |_____________|________________
O | |
P | |
E |_____________|________________
IMPACT
But there is one more dimension that some of the definitions revolve around - its the life of decisions. If the decisions live through the life of the product, most likely they will be architectural. This also means that these are decisons that are almost irreversible. Changing them is very difficult.
Architectural decisons are typically taken early in project lifecycle.
The above two points again tie into Scope-Impact model. Because of big scope and high impact the decisons are important enough to be taken early on. And the importance also guides the reversability.
Ofcourse each of these definition has exceptions. Once we have architecture, important thing is that Architect owns this. Own means - create, make changes and discard/replace at appropriate times.
For budding software architects
A time comes in life of a software engineer, when he can't remember last time he debugged or fixed a bug. Design and coding are still part of the job, but he has been leading projects. And suddenly he begins hearing about next quantum jump called architect. It is like an electron moving from inner orbit to valence orbit, ready to join the club which will create semi-conductor properties in a silicon.
What is not very clear is the meaning of quantum jump? More unclear is the path to becoming one. This blog is about throwing light on various aspects of architect.
What is not very clear is the meaning of quantum jump? More unclear is the path to becoming one. This blog is about throwing light on various aspects of architect.
Subscribe to:
Posts (Atom)
