Self-appraisal on the numerous areas for improvement towards an application architect. You don’t have to reply, but your comments are definitely welcome.
First off, a shortlist of key metrics (among many metrics) for an enterprise application architecture. In fact, an architecture is evaluated on these criteria
* flexible + extensible + adaptable + resilient, for changes in volatile environments where requirements change frequently and need quick implementation. Not rigid or fragile. Will we be forced to scrap our current architecture and rebuild from scratch, or our current architecture can adapt to changes?
* performance — and throughput, capacity, and cluster support. Frequently, these are absolutely essential requirements an architecture must meet, or else the architect is disqualified.
* testability — quality assurance
* Cost — hardware/software cost often pale in comparison to labor cost. Cost improves when an architecture is more resource-efficient, easier to Learn, more Adaptable to changes, faster to Test, or offers faster Speed-to-market
* speed to market — Speed improves when an architecture becomes more Flexible/Adaptable, more Testable, or easier to Learn. Any experience/knowledge can help an architect make faster and better decisions.
* ease of learning (and maintenance) — simplicity helps learning.
Now, my own room4improvement:
– UML.– helps Learning, and perhaps Speed, since it facilitates communication.
– unit testing — for both OO and batch/scripting. I think there are many tools, real-world challenges/solutions.
– OO design patterns
Helps Flexibility, Learning,
– IDE — Not sure about small companies, but many large company (my focus for now) developers use IDE.
These tools affect Learning and Speed-to-market, but a non-IDE programmer may understand troubleshooting a bit better.
– API design — A poorly-defined skill. I think an experienced architect can somehow design better API interfaces between API-team and “client developers” who use the API. “Better” in terms of Flexibility, Testability, Learning, Speed-to-market, and simplified communications.
– DB schema design — The territory of data architects. Large companies (my focus for now) may or may not separate data architect and software architect roles.
– DB system design — stored programs, constraints, views, indices, locking, tuning … DBA’s duty. Software architects depends on and work closely with DBA, so deep knowledge is not absolutely required but important for a good software architecta — basic knowledge suffices. In reality, “basic” knowledge in this area is a rather high expectation.
– reporting — enterprise reporting, management reporting … There are many tools and common solutions. Reporting is a common functionality, found in perhaps 30% of current enterprise projects. An Architect may not need BI (Business Intelligence) but need a decent knowledge of reporting. Otherwise his credentials are somewhat in doubt.
This skill helps Speed to market, since it probably results in a more proven design — less trial-and-error.
– mem leak — tools, nlg, experience. I think an architect may be called to solve such problems.
– prototyping — A poorly-defined composite skill. Rapid prototyping and proof-of-concept. Personally I tend to favor these more than UML and product brochures.
This skill helps Speed to market, and can improve Cost by reducing unnecessary purchases.
– capacity planning — for hardware and software. I had a long-time friend, a SAP capacity planner and performance tuner. CP seems to be such a niche that few architects have expertise. I think in large companies (my focus for now), there are designated experts/approaches to decide how much cpu/bandwidth/DB-license… to buy. An architect is often involved in cost-estimation and need CP knowledge.
This skill helps Performance, Cost and Speed.
– code generation — I think some java architects are not knowledgeable about code generators like xdoclet. Code generators can be very effective. However, lack of such knowledge may not affect an architect’s performance appraisal, even though it can dramatically affect the team and the system built.
This skill helps Speed, Flexibility
– profiling/benchmarking — for performance-sensitive systems. There are many tools
– app-servers — knowledge of their relative strengths and limitations, and when to avoid each. Also how to work around their weaknesses, when you have to deal with them.
– OS features — that affect applications, such as OS tuning, threading, CPU/RAM allocation. One of my strengths.