What does an Application Architect Do?
And how do you do it?
November 09, 2018
Most folks say, "Protect your IP." Intellectual Property - not Internet Protocol! I'm not going to preach , but I believe in sharing and giving generously (unless it's my wife, coffee or croissants). So here's what I do and how I do it...
I'm a software architect. Do you have to go to school? Not always. You just need to be intuitive and good with tech and code.
Long starry eyed version: What I do is make your tech dreams come true. How I do it, is by using discipline, creativity, skill, confidence and memory. Yeah, I'm that cool -and humble! Let's break that down.
Your tech dreams come at me in different ways. Like - An extra belly button. A desperate email or phone call. A function doc replete with explicit objects, attributes and names (not from an adult store - c'mon we're PG-13). A brainstorming white board session where the C level guy says, "I want to have a dashboard view of all our important stuff" -C level guys always talk like that. NO MATTER HOW THEY COME AT YOU - You cannot freeze like a crappy right-fielder praying that no-one actually hits to you - don't blow it Smalls!
Discipline. You also CANNOT jump on that project like a middle-aged fat man on a Thanksgiving sweet potato casserole with forks in both hands which is my first inclination to both of those. BUT First, let's find out what they really want. I was told, they want A. What they really want is A123. Neither of us know what the 1-2-3 part is. And I will never know what they actually want unless I chill for a minute, think about what they said, then ask a bagillion more questions (without boring them or pissing them off - Note: you really need to read the room like Daniel Negreanu. The better I am at this, the more money or credit I make. Piratey voice: "Tricky waters these, but rewards thar be!"
Think Larry King not Alex Trebek. You know where you wanna go, but you let your guest get you there. You're even willing to take unexpected paths. But your questions are pretty much what you expected before you were hit with the project. And you only ask the ones you don't already know the answers to.
Here they are:
- Who are your users?
- How many people will actually interact with this?
- How many will input?
- How many will see it?
- What are their day jobs and job titles?
- What is your environment?
- How much latitude and decision making authority do I have?
- What tech stacks are allowed?
- Version Control?
- Sandbox, Development, and Production?
- Online? In-house?
- Windows and/or Apple and/or Unix?
- Hosted where?
- Will this interact with other apps?
- Does this have to be compliant with some government or industry regulation or standardization?
- ** What is your data?**
- What are your distinct groups of objects?
- What do your objects do and how are they related to this project?
- How much info do you need to know and how long do you care to know it?
Note:-This is the most important data question. This will tell you how many rows and how
- ** Who will I be working with?**
- Other programmers? - What are their skills or specialties?
- Designers?
- Key stake holders?
- Users?
- What is the Final product like?
- An app?
- An app that will have custom developments based on the client?
- A report (be it paper, online, email, charts, etc.)
- Will it need to be available to other apps? (Like an API or Web Service)
Creativity. Now comes the artsy fartsy part- sy. Shutup. I'm a musician - not a great one, but not bad. Every good developer has his feelings side, and this is one of the important times to use it. Begin to brain-storm and envision the actual end-product. Work backwards from there and see all the parts. OK now I sound like Obi-Wan coming across Luke's visor. Whatever, just picture a working model and how you might get there from a 500 foot view. The trickier or more unique the problem, the harder this is and why we make the big bucks. The key to this step is iteration. This is the imaginative demo-ing phase. Just like we do the actual demo and user testing pieces, is how we do this but the medium is either a white board or our mouths. No I don't blow kisses at people, unlike my underwater MerMan son, I just voice what I'm picturing to see how it resonates and then modify it based on my feedback.
Skill. This is learned, practiced, fiddled with and at the heart of a coder. It's frickin' fun and cool and what makes us who we are. We code. I'm agnostic when it comes to a language and pretty much when it comes to everything else except ironically God. I don't have any strong opinions about editors, syntax, object-oriented vs event driven, API or really anything. I have the end in mind and whatever mandate I'm working with. If I get to choose - everything, then it will probably be a Node.js app connecting to a SQL- Server back-end with a thin browser based front-end using very few if any frameworks or libraries and be able to consume and provide some RESTful APIs. Sure I like C#, Java, REor wThe specific language I'm working with at the time is not important, just that I'm proficient at it.
The stuff below is just my notes to finish this article...
* **Do you need a good designer?
- Business Logic Layer
- Front End - multiple versions depending on the userType
- Apps - multiple based on userType or deviceType or module
- 3rd party pieces - are there a lot? are they with big names like ORACLE or MicroSoft? Are they dependent on a particular version?
- How to logon
- Branches per client
- Overall diagram
- Function Diagrams
- Documentation
- Tutorials
- Collaboritive
- Web Services or not
- Selling pieces (like web services or generic apps, or by client or add-ons)
- Current knowledge / familiarity of in-house personnel for usability and maintenance -languages, platforms, user interfaces, report engines -how easy is it to find programmers or will it be supported later
- will this grow? or will it just fit in with other stuff you have or the client already has
- Hard core tool or novelty?
- Public Visibility