Rosen : Quickly create an architectural vision and strategy. It should take about two months to develop this high-level architecture. Use this to prioritize and guide the implementation of the architecture. I agree with this but be careful. This really depends on the scope of what you are architecting. I believe the duration aspects applies to how substantial the architecture works are. As an example, you wouldn't want to tell your business unit that it will take 2 months to come back with a design for a small LOB application with 10 users. However this would be perfectly acceptable for a mission critical system such as the corporate CRM system.
Rosen : Pick an appropriate project to start implementing the first pieces of architecture. Choose one that is important enough to get noticed but not so critical that outside pressures will make it impossible to do the right things. This is a great one! I couldn't stress any more on getting the quick incremental wins. Deliver quality rapid bite size nuggets of good solution architectures and they will be hungry for more. They may even install the architecture buffet line.
Rosen : After every project, integrate the lessons learned into the next iteration of the architecture. Keep it current. Constantly solicit feedback from development. Get buy-in by demonstrating that architecture makes the job easier. I agree with the practice of collecting lessons learned is critical for almost every thing you do but I think there is something significant missing here. I will talk about this in a future post but I will give a high level overview here because I think it makes sense. One of the greatest challenges with architecture models and documents is they only tell you the "what" and sometimes the "how". Often times they do not describe they "Why" question. I would assert that this is the most important of them all. So, through the architecture description process you want to itierativly capture the architecturally significant decisions as you work through your descriptions. This should capture the trade-off analysis that you as the architect went through to deicide whether this solution should as an example go to a 3 tier DMZ or just a single limited protected tier. It will also help with traceability to business architecture and as a result of the process provide something that has missing for awhile in architecture, accountability on all sides of the process. We can get accountability because we can enforce approvals of these architecture decisions by not only the architect but all others involved in aiding in the decision such as the VP's, Directors of development areas, Business Analysts, Business Solution Owners, etc.
Rosen : Implement, collect, and report metrics to prove the value in terms of cost, time, and quality. Ideally, you should define metrics that are generic across all architecture initiatives to ensure you can baseline the metrics and correlate them to show measurable results. This maybe what Rosen is referring to here. But if not, you have my thoughts.
Rosen : Know the difference between great and good enough. It will never be perfect. Good enough delivered on time beats late but great every time. This is another gem. Knowing when to quit is definitely a skill. It is easy to loose focus. I call this "over architecting". No solution is perfect and architects should keep that in mind when building solutions. But, you do need to keep all the critical quality attributes of the architecture in mind when you are building and make sure you fulfill those. Also, your work isn't done by saying that this architecture is "good enough". You still need to define the road map for the architecture, create a risk mitigation plan (if needed) and lessons learned. Like I said earlier, Rosen brought up some great points and provided valuable insights for architects. Check out his full article here: http://blog.cutter.com/2009/03/19/death-by-architecture/
Technorati Tags: Enterprise Architecture, Architecture, Documentation, Process
留言