•Amazon Elastic Beanstalk
•CloudBees Run@Cloud
•Cumulogic
•Google App Engine
•IBM SmartCloud Application Services
•Microsoft Azure
•OutSystems Agile Platform
•Red Hat OpenShift
•Salesforce.com Heroku for Java
•VMWare CloudFoundry
•WSO2 Stratos/StratosLive
понеділок, 28 листопада 2011 р.
понеділок, 21 листопада 2011 р.
Hosting
Last week I noticed a lot of posts regarding pricing for Cloud hosting. Most of the authors states that this approach is more expensive in (1,5 - 5) times. As per me it’s reasonable since using virtualization means that hardware is shared and performance is less in comparison with managed hosting and private datacenter.
Here is my thoughts what hosting should be used and for what reasons:
1. Cloud – mostly applicable for startups. Low price for upfront investment, ability grow very quickly since adding new virtual machines are very easy thru API interface. Hosting expenses has less priority than getting more customers in short period of time.
2. Private Data-centers – Applicable for the solution if your operation team has experience for hosting similar SaaS products, Ops processes are established and you have clear vision how new system will be operated and loaded.
3. Managed Hosting – Same as above except – no huge upfront investment for hardware. Please note that managed hosting monitoring will cover monitoring of servers availability and does not cover application and services availability
As a conclusion – please select type of hosting carefully and take in to consideration whole Pros and Cons for your solution and look for one or two steps ahead in the future. Because you may lose a little now but get huge benefit in the future …
Here is my thoughts what hosting should be used and for what reasons:
1. Cloud – mostly applicable for startups. Low price for upfront investment, ability grow very quickly since adding new virtual machines are very easy thru API interface. Hosting expenses has less priority than getting more customers in short period of time.
2. Private Data-centers – Applicable for the solution if your operation team has experience for hosting similar SaaS products, Ops processes are established and you have clear vision how new system will be operated and loaded.
3. Managed Hosting – Same as above except – no huge upfront investment for hardware. Please note that managed hosting monitoring will cover monitoring of servers availability and does not cover application and services availability
As a conclusion – please select type of hosting carefully and take in to consideration whole Pros and Cons for your solution and look for one or two steps ahead in the future. Because you may lose a little now but get huge benefit in the future …
четвер, 17 листопада 2011 р.
Most large-scale web sites technology map
I've found interesting post where author summarize technologies used for most large-scale web sites
вівторок, 1 листопада 2011 р.
Utah SaaS Workshop (Update)
As I promised, in this post I am publishing some materials about Utah workshop. Follow the link you could collect general information about workshop and see presentation what Russ provide. In additional to this I would like share some overview:
1. Personal communication is more valuable and help talk about details and suggest better approaches than general questions what come up during presentation and panel session
2. DB is the major paint for every one
3. Sometime even simple idea what is lay on top may be useful for clients
4. Abstract presentation may not be attractive for the participants – next time we may concentrate on the discussion solution for different problem solving from technical stand point and business impact.
5. Grate event :) and cool participants :):)
1. Personal communication is more valuable and help talk about details and suggest better approaches than general questions what come up during presentation and panel session
2. DB is the major paint for every one
3. Sometime even simple idea what is lay on top may be useful for clients
4. Abstract presentation may not be attractive for the participants – next time we may concentrate on the discussion solution for different problem solving from technical stand point and business impact.
5. Grate event :) and cool participants :):)
вівторок, 18 жовтня 2011 р.
Utah SaaS Workshop
This Tuesday, I’ve performing the Q&A session in SoftServe SaaS workshop in Utah. It was the first time when I was as front man and answer on questions related to the SaaS architecture and solutions. Good experience for me, meet new interesting people and of course observe what is an interest of the audience. I will post more details later but as a short summary – it was grate day and we (me, Serge – Director of Architecture Group and Russ – VP of SaaS) successfully hold this event.
середа, 27 квітня 2011 р.
Main reasons for Choosing Scale-Out
1. Continuous Availability/Redundancy: You should assume that failure is inevitable, and therefore having one big system is going to lead to a single point of failure. In addition, the recovery process is going to be fairly long which could lead to a extended down-time.
2. Cost/Performance Flexibility: As hardware costs and capacity tend to vary quickly over time, you want to have the flexibility to choose the optimal configuration setup at any given time or opportunity to optimize cost/performance. If your system is designed for scale-up only, then you are pretty much locked into a certain minimum price driven by the hardware that you are using. This could be even more relevant if you are an ISV or SaaS provider, where the cost margin of your application is critical to your business. In a competitive situation, the lack of flexibility could actually kill your business.
3. Continuous Upgrades: Building an application as one big unit is going to make it harder or even impossible to add or change pieces of code individually, without bringing the entire system down. In these cases it is probably better to decouple your application into concrete sets of services that can be maintained independently.
4. Geographical Distribution: There are cases where an application needs to be spread across data centers or geographical location to handle disaster recovery scenarios or to reduce geographical latency. In these cases you are forced to distribute your application and the option of putting it in a single box doesn’t exist.
2. Cost/Performance Flexibility: As hardware costs and capacity tend to vary quickly over time, you want to have the flexibility to choose the optimal configuration setup at any given time or opportunity to optimize cost/performance. If your system is designed for scale-up only, then you are pretty much locked into a certain minimum price driven by the hardware that you are using. This could be even more relevant if you are an ISV or SaaS provider, where the cost margin of your application is critical to your business. In a competitive situation, the lack of flexibility could actually kill your business.
3. Continuous Upgrades: Building an application as one big unit is going to make it harder or even impossible to add or change pieces of code individually, without bringing the entire system down. In these cases it is probably better to decouple your application into concrete sets of services that can be maintained independently.
4. Geographical Distribution: There are cases where an application needs to be spread across data centers or geographical location to handle disaster recovery scenarios or to reduce geographical latency. In these cases you are forced to distribute your application and the option of putting it in a single box doesn’t exist.
вівторок, 26 квітня 2011 р.
Softserve SaaS Dev Kit
In the youtube is video about my company SaaS initiative - I am happy that i put some effort in this initiative in the early beginning
to see video go
http://www.youtube.com/watch?v=q3RrsdnWWsI&feature=youtu.be&a
to see video go
http://www.youtube.com/watch?v=q3RrsdnWWsI&feature=youtu.be&a
понеділок, 25 квітня 2011 р.
Delivery Models
Found summary of the cloud service classification like Delivery models and Deployment models see previous post
Cloud services delivery can be broadly classified into three models. This is commonly called as SPI model.
1. Software as a Service (SaaS): Software applications delivered from the cloud using multi-tenancy and accessible by various devices using a web browser. The vendor controls the entire stack from hardware to applications with users having the control over their data.
2. Platform as a Service (PaaS): Application platform that completely abstracts all the complexities of the underlying infrastructure and delivered as a service for the users to deploy applications that can be accessed over the network. There are striations inside the PaaS itself with IDE as a service on one end to pure middleware as a service on the other end. For the sake of simplicity, we stick to the SPI model and consider various types of platform services within the PaaS categorization itself. The provider controls everything from hardware till the platform layer and users have complete control over their applications.
3. Infrastructure as a Service (IaaS): Raw compute power and storage offered as a service with a metered billing where users can deploy and run different software from operating systems to platforms to applications. Compared to PaaS, the abstraction is taken to a lower level in the infrastructure and users get more control over the configuration of platform itself. The provider manages the hardware and other infrastructure needed to run the virtual machines and the users get to control everything from OS to applications.
Cloud services delivery can be broadly classified into three models. This is commonly called as SPI model.
1. Software as a Service (SaaS): Software applications delivered from the cloud using multi-tenancy and accessible by various devices using a web browser. The vendor controls the entire stack from hardware to applications with users having the control over their data.
2. Platform as a Service (PaaS): Application platform that completely abstracts all the complexities of the underlying infrastructure and delivered as a service for the users to deploy applications that can be accessed over the network. There are striations inside the PaaS itself with IDE as a service on one end to pure middleware as a service on the other end. For the sake of simplicity, we stick to the SPI model and consider various types of platform services within the PaaS categorization itself. The provider controls everything from hardware till the platform layer and users have complete control over their applications.
3. Infrastructure as a Service (IaaS): Raw compute power and storage offered as a service with a metered billing where users can deploy and run different software from operating systems to platforms to applications. Compared to PaaS, the abstraction is taken to a lower level in the infrastructure and users get more control over the configuration of platform itself. The provider manages the hardware and other infrastructure needed to run the virtual machines and the users get to control everything from OS to applications.
Deployment Models
One of the most important model in the cloud services is – delivery models
1. Public Clouds: Public Clouds, also called as the real cloud by some purists, is the availability of cloud infrastructure to general public and accessible through the Internet. The infrastructure is owned by 3rd party service provider and is present outside the firewall of organizations using it. Multi-tenancy is the key differentiating factor here, which results in what we now call as Cloud Economics.
2. Private Clouds: Private Clouds are cloud infrastructure operated solely for an organization either by the IT of the organization or 3rd party. The infrastructure can be present inside of the organization’s firewall or operated in a 3rd party datacenter. Cloud economics will not be in play here but organizations can take advantage of other cloud characteristics like better utilization and elasticity.
3. Community Clouds: Community Clouds are cloud infrastructure shared by different organizations that supports specific community or verticals with shared needs. One or more of the participating organizations or a 3rd party may manage the infrastructure. The infrastructure can be present either inside the firewall or with 3rd party datacenters.
4. Hybrid Clouds: Hybrid Clouds are cloud infrastructure made up of two or more clouds (public, private, community) with one of them leveraged from a public cloud provider. These are independent cloud deployments that are bound together by standardized or proprietary technology that enables data and application portability. Usually, enterprises with a private cloud infrastructure tap into public clouds to push certain non-critical workloads in order to meet their sudden resource requirements
1. Public Clouds: Public Clouds, also called as the real cloud by some purists, is the availability of cloud infrastructure to general public and accessible through the Internet. The infrastructure is owned by 3rd party service provider and is present outside the firewall of organizations using it. Multi-tenancy is the key differentiating factor here, which results in what we now call as Cloud Economics.
2. Private Clouds: Private Clouds are cloud infrastructure operated solely for an organization either by the IT of the organization or 3rd party. The infrastructure can be present inside of the organization’s firewall or operated in a 3rd party datacenter. Cloud economics will not be in play here but organizations can take advantage of other cloud characteristics like better utilization and elasticity.
3. Community Clouds: Community Clouds are cloud infrastructure shared by different organizations that supports specific community or verticals with shared needs. One or more of the participating organizations or a 3rd party may manage the infrastructure. The infrastructure can be present either inside the firewall or with 3rd party datacenters.
4. Hybrid Clouds: Hybrid Clouds are cloud infrastructure made up of two or more clouds (public, private, community) with one of them leveraged from a public cloud provider. These are independent cloud deployments that are bound together by standardized or proprietary technology that enables data and application portability. Usually, enterprises with a private cloud infrastructure tap into public clouds to push certain non-critical workloads in order to meet their sudden resource requirements
10 main requirements for SaaS/Cloud applications
Find interesting post regarding 10 main requirements for SaaS/Cloud applications. Below is short notes:
1. True Multi-tenancy. Multi-tenancy is the only proven SaaS delivery architecture that eliminates many of the problems created by the traditional software licensing and upgrade model—period.
2. Regularly Delivered, Vendor-Managed Updates. A cloud application is a single version of software that is regularly updated, often several times a year, for all customers, at no additional charge.
3. Seamless Integration On Demand. Cloud applications should be built from the ground up to lower the cost, time, and risk of integrating them with existing on-premise and on-demand applications.
4. Business-Driven Configurability. Cloud apps should be configurable, so your IT organization is freed from costly customizations (the most over-rated virtue of traditional software, in my opinion), and businesspeople can configure processes that meet the specific needs of the organization. That said, you should be able to choose from among multiple types of configurations.
5. World-Class Data Center and Security. A cloud application provider should be able to offer world-class security and data privacy better than its customers can do on their own, and at no additional cost. That includes physical, network, application, and data-level security, as well as full back-up and disaster recovery. The provider should be compliant with security-oriented laws and auditing programs, including Safe Harbor, ISO 27001, and SAS70 Type II.
6. A High-Performance, Sustainable IT Infrastructure. The provider should maintain a high-performance IT infrastructure, which includes the data centers and databases, operating systems, networks, and storage systems used to run cloud applications and manage customer data.
7. Predictable Total Cost of Ownership Model. There should be no surprise costs with cloud applications. Implementation costs should be predictable, subscription-based pricing should have no hidden fees, and no investments should be required for hardware and software license fees.
8. Faster Deployment. Since cloud applications don’t require investments and installation of hardware and software, you should be able to get them running and productive in a fraction of the time compared with on-premise software.
9. Control. Cloud applications should allow you complete control of your organization’s data, even though it is located off premise. Nothing should hinder your ability to import, export, purge, and archive data to and from the application without having to first contact the SaaS vendor.
10. Liberation from Non-Strategic IT Issues. Cloud applications should free teams from time and energy spent on non-strategic, back-office IT operations and software coding. Today and into the future, the most highly valued CIOs—the ones that become heroes to the business—are those who are closely aligned with strategic business initiatives and drive the IT projects that support those initiatives.
Original post is here
1. True Multi-tenancy. Multi-tenancy is the only proven SaaS delivery architecture that eliminates many of the problems created by the traditional software licensing and upgrade model—period.
2. Regularly Delivered, Vendor-Managed Updates. A cloud application is a single version of software that is regularly updated, often several times a year, for all customers, at no additional charge.
3. Seamless Integration On Demand. Cloud applications should be built from the ground up to lower the cost, time, and risk of integrating them with existing on-premise and on-demand applications.
4. Business-Driven Configurability. Cloud apps should be configurable, so your IT organization is freed from costly customizations (the most over-rated virtue of traditional software, in my opinion), and businesspeople can configure processes that meet the specific needs of the organization. That said, you should be able to choose from among multiple types of configurations.
5. World-Class Data Center and Security. A cloud application provider should be able to offer world-class security and data privacy better than its customers can do on their own, and at no additional cost. That includes physical, network, application, and data-level security, as well as full back-up and disaster recovery. The provider should be compliant with security-oriented laws and auditing programs, including Safe Harbor, ISO 27001, and SAS70 Type II.
6. A High-Performance, Sustainable IT Infrastructure. The provider should maintain a high-performance IT infrastructure, which includes the data centers and databases, operating systems, networks, and storage systems used to run cloud applications and manage customer data.
7. Predictable Total Cost of Ownership Model. There should be no surprise costs with cloud applications. Implementation costs should be predictable, subscription-based pricing should have no hidden fees, and no investments should be required for hardware and software license fees.
8. Faster Deployment. Since cloud applications don’t require investments and installation of hardware and software, you should be able to get them running and productive in a fraction of the time compared with on-premise software.
9. Control. Cloud applications should allow you complete control of your organization’s data, even though it is located off premise. Nothing should hinder your ability to import, export, purge, and archive data to and from the application without having to first contact the SaaS vendor.
10. Liberation from Non-Strategic IT Issues. Cloud applications should free teams from time and energy spent on non-strategic, back-office IT operations and software coding. Today and into the future, the most highly valued CIOs—the ones that become heroes to the business—are those who are closely aligned with strategic business initiatives and drive the IT projects that support those initiatives.
Original post is here
середа, 23 березня 2011 р.
Large-Scale Agile Design & Architecture: Ways of Working
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.
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.
понеділок, 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)