Nine SDLC Cross-Functional Areas

I met the very impressive Kim Hardy at an IIBA Meetup in Pittsburgh a few weeks ago. She is passionate about relating her insights to people, their needs and values, and how to make them effective, engaged, and happy while realizing their organizational goals. Last Friday we got together online and she walked me through an analytical framework she’s been building up as part of her “People First” Agile coaching practice. I don’t want to give away her ideas, you should seek those out on your own, but I do want to share one insight she’s developed that resonated with me strongly. I’m not suggesting that it’s entirely unique because I think we all implicitly understand the categories she defines, but sometimes the most powerful insights come from clarifying things everyone already knows in a pithy way.

The specific clarification has to do with identifying nine cross-functional areas within the SDLC process. Ms. Hardy’s consulting practice aims to ensure that each Agile team includes members that are knowledgeable in — and hopefully passionate about — each of the nine areas. The work will usually get done even if this process isn’t followed consciously, but consciously applying it cannot help but clarify lines of responsibility, give more team members a chance to shine, and clearly identify areas that need attention.

Before proceeding I want to observe that while this breakdown scales to efforts of every size, it’s probably most important to apply explicitly on larger efforts. Larger efforts involve the most people, require the most coordination, and incur the greatest overhead in each functional area. By contrast, when I wrote model-predictive control systems for the steel industry I worked with one other person some of the time and by myself more than half the time. I (or we) had to interface with other computers within the furnace control system and with other plant systems but within the Level 2 supervisory control system I worked alone (or close to it). My sometime co-conspirator set up the hardware, VMS OS, and communication programs on DEC VAX and Alpha systems while I wrote the simulation and control code. On Windows-based systems I did it all on my own. I had to be reasonably competent in all nine areas. At that time (1994-2000) I didn’t take as high level a view as I do now. With more analytical and organizational experience I have a deep feel for all of these areas, but I have specialized more in the abstract discovery, data, and decision areas than in the technical implementation details.

The nine areas are:

Business Value: Supporting organizational goals

User Experience: Ensuring that users are empowered to execute their duties with clarity, speed, and accuracy

Process Performance: Executing project schedules efficiently and effectively

Development Process: Ensuring that developers have the tools, training, insulation, and support they need to produce excellent work

System Value: Creating systems that realize an organization’s business values

System Integrity: Ensuring systems are secure and robust

Implementation: Developing code that is efficient, free from defects, and addresses the organization’s values

Application Architecture: Ensuring systems are maintainable, modifiable, reusable, understandable, and so on, and ensuring that the business needs are addressed

Technical Architecture: Employing the most capable technologies possible

This classification and clarification resonated with me in particular because I’ve been trying to communicate where my current strengths and passions lie. Using this breakdown I assigned levels of preference to each area of practice as follows:

This says that the primary areas of importance to me at this stage of my career are those that solve a problem for an organization. Accordingly, I have specific explanations for why I value each area the way I do.

Business Value: I’m all about solving the right problem. Identifying an organization’s problems, needs, and requirements should come before any other consideration. Like you don’t plug numbers into the equations until you’ve defined the equations that describe and solve the problem, you don’t implement the solution in detail until you until you’ve defined and “solved” it in the abstract. This means that you concentrate on the logical and operational needs of the people and organization first, and only then do you work out the specific implementation.

User Experience: I’ve been building user interfaces and animations and conveying information for a long time. I’m keenly aware of the need to let users manipulate things in an efficient, powerful, and flexible way while at the same time guiding and constraining their actions to prevent errors, maintain situational awareness, and support an organization’s business goals. I care what users can do and am passionate about seeking and incorporating their feedback, but I’m less interested in the specific technologies used to implement the capabilities that let them do it.

Process Performance: This is about project management, Agile methodologies, and maintaining cohesion, buy-in, and enthusiasm. I have experience, insights, and/or certifications in all of those areas but think my greatest value-add comes from streamlining the design and requirements process. I always try to break processes down into their simplest, most general actions and representations so complex systems can be built up from the smallest number of generalized components. This allows a technical team to construct the smallest number of code units that implement the components so systems of arbitrary complexity can be built using just a few of them. Different systems are more and less amenable to this approach but I’ve had the good fortune to work on many applications where the approach is extremely effective. All good practitioners look for efficiencies, modularity, and opportunities for reuse.

Development Process: Caring about details of the development process is a function of being in the bit-slinging trenches every day. I mentioned that good practitioners always try to be more efficient, and coders and their coordinators tend to apply that impulse to methods that streamline their areas of concern. I love coding but at this point, for me, it’s a way to understand what the developers are doing, stay in touch with the current state of practice, and be able to relate general concepts to newer developers and non-technical individuals. I met a gentleman at a Build Night at Pittsburgh Code & Supply who walked me through the tremendous automations he had arranged for building and hosting websites directly out of GitHub. I am aware of those technologies but I don’t use them directly in my work and I observed that his “web fu” was far, far beyond my own. I realized at that moment that I totally didn’t care that that was the case, and recognized that I’m glad the people have different skills and interests. I didn’t care, and that was totally OK (for me, anyway, if not for you — there isn’t time to learn it all). The point is to work with teams where members have those skills and passions, and ensure they get the support they need to develop and apply them in peace.

System Value: I’ve stated above that my passion for solving problems abstractly before they are addressed concretely, as well as identifying opportunities for simplification and modularity, should lead inevitably to creating systems that directly and efficiently realize business value for organizations.

System Integrity: A lot of this has to do with cybersecurity, social and organizational engineering, and control of information. It’s not that I’m not interested in these things per se, it’s just that they aren’t what I prefer to concentrate on. I contribute in this area by being aware of what’s going on, building organizational systems for governance, and ensuring that the proper specialists are engaged to address the details.

Implementation: I care about efficient, modular, clear, documented code in a general way, and in particular ways when it comes to certain classes of solutions, but I’m less about build and deployment workflows and details than I am about optimizing on the right things so a system or portfolio’s total cost of ownership is minimized. This means knowing how to balance development time and squeezing out that last bit of performance, accepting the easy-to-write and -maintain abstraction in place of the custom coding job, space/storage/bandwidth/responsiveness tradeoffs, and so on. Again, there isn’t time to learn it all.

Application Architecture: For the nth time I’m all about realizing business value by ensuring that the correct information is gathered, processed, transformed, routed, and output in the process of providing effective control and decision support. I care what goes where, when it goes there, who it goes to, and why more than I care exactly how any of that happens. The W’s are the abstractions that provide the business value. The H is the instantiation of those abstractions. I refer to these considerations as the “solution space,” as opposed to the “tool space” described in the next section on Technical Architecture.

Technical Architecture: I give this the lowest level of concentration (again, for me) because I’m interested in solving organizational problems and those of the people within an organization. React vs. Angular? There’s an answer that a dedicated coder would care about but it’s not a concentration of mine. Oracle SQL vs. MySQL vs. NoSQL? Use whatever makes you happy. I’ll help design the schemas, you optimize the best way to work with them. C# vs. Java vs. C++ vs. SLX vs. goodness knows what else? Depends on the problem. Each individual will naturally know a related subset of specific languages, frameworks, development tools, and methodologies. My method is to analyze problems at a more abstract level, and then help technical teams implement solutions using their preferred tools and techniques. Having worked with a dozen different languages and having read about even more the one thing I appreciate is that they are all arise from unique historical circumstances and are designed to solve slightly different problems.

I’ve spent a lot of time looking at placement ads in the tech industry over time and see that they tend to list easy-to-label technologies that can be readily screened by ATS systems. Moreover, they often ask for lists of skills, in combinations and at levels of experience that are, to be polite, wishful thinking. I therefore try to talk in terms of these cross-functional areas. It helps people and organizations, build teams, manage processes, and identify opportunities in an interesting and clear way.

This entry was posted in Management and tagged , , , . Bookmark the permalink.

Leave a Reply