An Architecture-Driven Team Capability Model
After a few years in written form in my notes and in the blog, I believe the “8 core computing techniques” is mature enough to have a more official or formal name, so that it can be used in any documents in the “corporate culture”.
I put some thought on it; the best way for it to "break in" the corporate culture is to use it as a "capacity model" (note that it is not just a “process” -- it has much more content). Because it is all about architecture, so, it is an architecture-driven capacity model.
1. A person’s or a team’s CAPABILITY is determined by its ARCHITECTURE CAPABILITY.
---- I know, this is a peculiar usage of the word “architecture”. Please see below.
2. A person’s or a team’s ARCHITECTURE CAPABILITY equals:
“Business knowledge”
+ “Technologies”
+“Processes”
All of those are elements of architecture:
(a) “Business Knowledge” simply means (i) OR mapping, (ii) OU mapping, and Rules.
(b) “Technologies” simply means (i) Transactions (note: capable of unit-testing at this level is like logging, is part of the architecture, it is NOT just a feature of a “process”), (ii) Networks, (iii) Logging, and (iv) Security.
(c) “Processes” simply means the “order of doing things”, based on the DEPENDENCIES in the architecture.
posted by survic at
10:54 PM
4 Comments:
I will surmrise you whole post in one word i.e., velocity
http://www.versionone.com/Resources/Velocity.asp
:)
Vikas
No, I am different and special :-)
Seriously, my angle is very different. It is not about lightweight or heavyweight, or, process-centric or mature-developer-centric anymore. Process is just some changeable iterations or actions based on dependencies in the structure.
The key is about always keeping the “structure” in the central place. "Requirement" is just part of the structure, process is just the ad hoc dynamics of the structure. It implies that let's do not waste time on process and requirements, instead, let's go straight to the discussion on dependencies and screen and data and their mappings – there is no such thing as “requirements” or “process”, it is just the system and the (arbitrary – within the limits that the structure of the system allows) steps of actually building the system.
It is like XP’s “the code is the design”. However, it has a wider perspective, it says, the system is the design. As result of the fact that it uses a wider perspective, it can go even further, be more extreme -- it totally throws away traditional “process” concept – there are no “stories”: stories are simply the screens/data/mapping between them and rules, or, stories are the unit testing, networking/messaging, security, and logging.
It reduces “users” into the system, it reduces “time (i.e., process)” into “space”, and it amplifies the system/space, put the system in your face.
The best of the whole thing is that it says that unit testing is just like logging. It is a default architecture item, instead of a process item – a few years ago, logging is not part of architecture, but now, everybody agrees it is. The same thing applies to unit testing – it is not a process item, it is simply part of the default architecture.
survic
clarification on: there are no “stories”: stories are simply the screens/data/mapping between them and rules.
---- if you cannot talk about screens/data yet, then, talk about them vaguely, and gradually, you will make them clearer and clearer. the key is that the process is ad hoc and gradual, as a result, there is no "stories" or "requirements", only vague screens/data.
survic
The simplify this “process”, for any projects, large or small, just put up an architecture post (if it is a larger project, put a larger post; a smaller one, a smaller post!), and use it from the very beginning – that means, you have to decide the architecture in the beginning, the first day (smaller project), or, the first week (larger project), and use the post again and again.
Everything is an drill-down item from there. Everything is design, which is part of architecture. There is no so-called “XXX gathering” or “according to Process” – if it is not in the architecture-design, then, it is not needed, has no value, and therefore should be cut, hence lean.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home