This week I’ve read topic about architecture on the InfoQ - Large-Scale Agile Design & Architecture: Ways of Working
There is a lot of suggestions about Agile architecture and thoughts around Astronaut Architect, Power Point Architects and etc.
For some reasons such architects are really does not bring any benefits for the projects inside the big company, but from other side if the hierarchy with in company properly organized they will bring a lot of the benefits. Just of example, some of the main role of the PowerPoint architect to talk with managers or customers about why we need refactoring, why we need change something and what goal should be accomplished. The example provided by author regarding the selecting processor just confirm that company does not have good communications inside the development.
Also author is talking that real architecture is the source code and that is true, but when project starts and only limited people involved in to the initial stage the role of the architect and having initial architecture on the paper is really important. Architect and paper architecture are main information about what we are really building and used for teach developers about components they will work on. Architect should keep in mind all components and he is the primary decision maker for any cross components aspects. When team start coding, his role transforms to the Master gardener, who is looking around, check implementation, code quality, and how architecture grows.
However many important practices was introduced in this topic that may really help to build architecture. My favorite is Design Workshop. If you have team with preliminary same level this session will help you to establish the common vision for the development and help to identify holes in the architecture in the latest stages. For one of my project where we had star team we doing workshops very often and it helps us to deliver feature in time with maximum features and this code still alive in the production.
Also mentioned standard approaches about decoupling components, abstraction from specific realization, TDD, and other practice but this is an general things what everyone should.
The last thing I would like to emphasize regarding architecture in the Agile – you like architect should control implementation because due focus on the features development team has temptation implement something quickly and then left it as is for the final release. This situation like what author mentioned about garden. So keep your ayes opened, review code on regular basis to avoid surprise in the end.
середа, 23 березня 2011 р.
понеділок, 14 березня 2011 р.
Small changes vs rewrite components
Just wake up after long fly, Baggage is lost in the Chicago so have a fun yesterday evening. During the fly have many time to thinking about how to transform the legacy application to new technology and what is the best approach.
I hear a lot of time when people telling me if we have 24 million dollars and 3 year we may rewrite application but now we didn’t have big budget and time is limited.
Small changes vs rewrite components
In life exists two approaches how to move application to new technology
1. Horizontal – when rewrites one of the layer (UI, Business, DAL, …)
2. Vertical – when application splits into logical modules and rewrite everything starting from DB and finishing UI
The first approach is good when you have good layers divided by interface and this is approach is good for the End User since usability experience will be changed at once and will not have transition period.
Second approach mostly used to resolve two issues – scalability and improve application architecture. It allow to rethink about existing functionality, optimize code, optimize UI so general improvement of application.
So what to approach select when budget and time limitation occurs?
Per my understanding and feeling I would suggest the following
1. Define long term goal
2. Analyze performance and other most critical issues
3. Predict in 3 – 5 years how your customers will grow
4. Analyze available resources
Only after this make any decisions
For example if you have event now some troubles with scalability and your goal move to SaaS I would strongly suggest using vertical approach
If you comfortable with scalability right now and didn’t expect any significant changes in nearest future, architecture is quite good I would suggest use horizontal approach.
As the last thought don’t forget about approach 20 X 80 when you change 20 % of functionality what cover 80 % of client needs may be this is a good start for doing new application from scratch …
I hear a lot of time when people telling me if we have 24 million dollars and 3 year we may rewrite application but now we didn’t have big budget and time is limited.
Small changes vs rewrite components
In life exists two approaches how to move application to new technology
1. Horizontal – when rewrites one of the layer (UI, Business, DAL, …)
2. Vertical – when application splits into logical modules and rewrite everything starting from DB and finishing UI
The first approach is good when you have good layers divided by interface and this is approach is good for the End User since usability experience will be changed at once and will not have transition period.
Second approach mostly used to resolve two issues – scalability and improve application architecture. It allow to rethink about existing functionality, optimize code, optimize UI so general improvement of application.
So what to approach select when budget and time limitation occurs?
Per my understanding and feeling I would suggest the following
1. Define long term goal
2. Analyze performance and other most critical issues
3. Predict in 3 – 5 years how your customers will grow
4. Analyze available resources
Only after this make any decisions
For example if you have event now some troubles with scalability and your goal move to SaaS I would strongly suggest using vertical approach
If you comfortable with scalability right now and didn’t expect any significant changes in nearest future, architecture is quite good I would suggest use horizontal approach.
As the last thought don’t forget about approach 20 X 80 when you change 20 % of functionality what cover 80 % of client needs may be this is a good start for doing new application from scratch …
середа, 9 березня 2011 р.
Stack Overflow Architecture
Most of you know that High Scalability resource is the best if you looking information about scalability, reliability … But most of the information are concerning about Java and NoSQL database. Last week they provide good post about Stack Overflow Architecture for revise solution what based on the Microsoft stack.
Stack Overflow Architecture post will be interesting for the any architects to realize what is behind of architecture. I am talking about tools, environment configuration is used to save over 95 million of page views in a month.
If you review references in the post you may find topic about lessons learned what as per me is really useful and give you some feedbacks about hosting challenges on datacenters.
Database aspects of this posts are related to DB schema what is really critical for hosted solutions because most of the performance issues are there. My favorite thing about SQL is question why they do not use NoSQL database – the answer is quite simple – if current solution what is based on MS SQL 2008 feet their needs and simplify their development why they should invest many to migration?
Additional interesting aspects is strategy for Scale Up what Stake Overflow is following. Most of us thinking lets setup/rent/buy more servers and it solves our issues but if you pay licensing fee this will be significant expensive.
As the final shoot – please read this post it contains a lot of interesting references to another topics and before use any approach what is posted on any site please think carefully if it’s really fit you and you have budget for this …
Stack Overflow Architecture post will be interesting for the any architects to realize what is behind of architecture. I am talking about tools, environment configuration is used to save over 95 million of page views in a month.
If you review references in the post you may find topic about lessons learned what as per me is really useful and give you some feedbacks about hosting challenges on datacenters.
Database aspects of this posts are related to DB schema what is really critical for hosted solutions because most of the performance issues are there. My favorite thing about SQL is question why they do not use NoSQL database – the answer is quite simple – if current solution what is based on MS SQL 2008 feet their needs and simplify their development why they should invest many to migration?
Additional interesting aspects is strategy for Scale Up what Stake Overflow is following. Most of us thinking lets setup/rent/buy more servers and it solves our issues but if you pay licensing fee this will be significant expensive.
As the final shoot – please read this post it contains a lot of interesting references to another topics and before use any approach what is posted on any site please think carefully if it’s really fit you and you have budget for this …
вівторок, 8 березня 2011 р.
Usability Mistakes
8 Usability mistakes
Just have a chance to read this white papers and definitely agree with author. So they are following:
1 Displaying All Important Information On “One Screen”
On daily basis we dial with product owner what data should be displayed on the screen, how many of them are important for the end user, can we load data partially or only summary? Author provide some suggestion, reference to the researches and specify that development team should be close to the user and clearly understood what they really do. Case to put everything in one place will not works for 90% of the users because they have different roles and needs.
2. Focusing On Features Rather Than User Tasks
Common mistake of all development teams - more features more powerful software... No comments for this :) I thought same before start working in the support. After one month support experience I've realize that user use product absolutely in different way we assume during development
3. Directly Mimicking The Paper-Based World
This case is common when user show how now he deal with paper work flow and ask us to automate this process - guys stop here and think what flow and UI will speed up user work and make their life easier
4. Not Validating Correctly With Users In The Field
This item is mostly concerned about get right feedback from right people - Described some use cases how this issue could be resolved
5. Focusing More On Customization Than Usability
Each organization is unique and may want additional steps in the flow or require additional information shown some where. If you simplify the process of customization and consider about it during design you may same money and time in the production because you will not need develop new and new features per each customer.
As summary really suggest to read this white paper since many important things are mentioned there. I've listed only 5 in my post since they are quite common and not specific to particular industry.
Just have a chance to read this white papers and definitely agree with author. So they are following:
1 Displaying All Important Information On “One Screen”
On daily basis we dial with product owner what data should be displayed on the screen, how many of them are important for the end user, can we load data partially or only summary? Author provide some suggestion, reference to the researches and specify that development team should be close to the user and clearly understood what they really do. Case to put everything in one place will not works for 90% of the users because they have different roles and needs.
2. Focusing On Features Rather Than User Tasks
Common mistake of all development teams - more features more powerful software... No comments for this :) I thought same before start working in the support. After one month support experience I've realize that user use product absolutely in different way we assume during development
3. Directly Mimicking The Paper-Based World
This case is common when user show how now he deal with paper work flow and ask us to automate this process - guys stop here and think what flow and UI will speed up user work and make their life easier
4. Not Validating Correctly With Users In The Field
This item is mostly concerned about get right feedback from right people - Described some use cases how this issue could be resolved
5. Focusing More On Customization Than Usability
Each organization is unique and may want additional steps in the flow or require additional information shown some where. If you simplify the process of customization and consider about it during design you may same money and time in the production because you will not need develop new and new features per each customer.
As summary really suggest to read this white paper since many important things are mentioned there. I've listed only 5 in my post since they are quite common and not specific to particular industry.
понеділок, 7 березня 2011 р.
Take Responsibility for the task.
We have multiple teams working on the same product. The main issue is that nobody think out of box (scope of the reponsibility).
Just simple example - something happens with QA Box, TL just sent email to CM and waiting for response. At this time QA are wating for testing, Developers waiting for server everybody waiting something. Why???
Most effective is to step 10 meters in the next room and verify status of the issue. Why TL is waiting to resolve issue what block his team? Why PM or Architect should ask him to stand up and took responsibility for his bloker?
I don't have answer on this question - just try to push TLs to do it ...
Just simple example - something happens with QA Box, TL just sent email to CM and waiting for response. At this time QA are wating for testing, Developers waiting for server everybody waiting something. Why???
Most effective is to step 10 meters in the next room and verify status of the issue. Why TL is waiting to resolve issue what block his team? Why PM or Architect should ask him to stand up and took responsibility for his bloker?
I don't have answer on this question - just try to push TLs to do it ...
неділя, 6 березня 2011 р.
The role of the software architect
Cool video that describes some Architect related things. I agree with all mentioned subjects there and suggest to take a look on this short video. See here
NDepend
We use NDepend as TL or Architect code quality control tool. In additional to FxCop and Style Cop tools. I am using NDepend to gather code project statistic. The main powerful features are
1. CQL language
2. Dependency matrix
3. Code difference explorer
CQL language - allow quick code browsing and identify most critical place of code based on the code metrics. For example detect dead code, complex methods, biggest types, methods and assemblies ...
Dependency matrix - helps me to identify cycle dependency cycles and get rid of them
Code difference - show changes between two snapshots what allow me to see interfaces changes. Very important for impact analysis.
1. CQL language
2. Dependency matrix
3. Code difference explorer
CQL language - allow quick code browsing and identify most critical place of code based on the code metrics. For example detect dead code, complex methods, biggest types, methods and assemblies ...
Dependency matrix - helps me to identify cycle dependency cycles and get rid of them
Code difference - show changes between two snapshots what allow me to see interfaces changes. Very important for impact analysis.
субота, 5 березня 2011 р.
Historical Museum
Just reviewed pictures from the my trip to Washington and realize that it was my first business trip as System Architect :) and this image like a symbol of my first steps on new position.
Who is SW Architect?
5 month ago i was promoted to new position - System Architect. From the first look no big difference with TL but after some time, i realized a big difference especially of level of involvement in project details. Right now i am handling two big projects for one of our customer and quite difficult to care about all in details. I'm trying to handle cross component connections and issues what i suppose most critical for the product since TL should handle component related details. Also i am trying to lead TLs what is really critical for us. I have big experience in lead teams so all my attention now is to help TLs to manage and lead people to achieve their goals.
Підписатися на:
Дописи (Atom)