My official job title is “Software Architect”. Some people do not like the metaphor of “architect” for designing software solutions. However, I actually think it is an apt description of the process required for managing enterprise software products. For those that don’t agree with the notion of architecture as a description of how a software system is designed, typically the argument is based around thinking that architectural design is equivalent to “waterfall“. I disagree with this argument and hopefully future blog posts will explain why.
Software is a set of instructions written for a computer such that the computer can repeatedly solve a problem in the same way every time that the problem is presented to it. The term “development” is a term that I dislike with regard to my profession. To develop something is to grow or expand it. I write software, i don’t grow it and I hopefully reduce it rather than expand it when I’m taking on an existing code base. So, I don’t like to call myself a software developer, I prefer the term software engineer for someone that analyzes problems and writes software to solve them. For this blog, the definition that I will use for the term “software solution” is: a set of instructions that allow for the automation of processes that solve a problem. The goal that I have as a “Solutions Architect” is to design a system out of discrete software solutions that can interact with each other in the most efficient methods to solve complex business problems.
Enterprise software is where my focus has been. I haven’t written software that is released for general consumption. Almost all of the software I have worked on in my career has been focused on integrating enterprise components to enable the organization to distribute information and processes more efficiently.
I started my IT career in 1999 when I transitioned from being a Director of Marketing – which is where my college education led me – to being the “webmaster” for the same company, which is where my avocation led me. I’ve been expanding my skills and experience in IT from the business-to-business marketing company to the health and insurance industry, followed by the financial industry then the education realm as the Senior Project Leader at an Ivy League university. I moved on to a consumer driven global corporation that was diversified across many different markets from mortgages and lending to lighting to formal men’s wear. I took a chance on a start up providing streaming videos via the subscription model and then moved to working at a defense contractor. Recently I moved back to a consumer driven corporation, this time, the company manufactures, sells, distributes and licenses its products; which isn’t very diversified, but has become extremely successful in the past couple of years and is going to be expanding into international markets soon.
I enjoy writing software because I enjoy being able to have concrete evidence that I have effectively solved a problem. Unfortunately, most of the time, programmers solve the wrong problem. They are not looking into why the problem exists and end up writing a solution that doesn’t meet the needs of the end user. My goal for this blog is to capture my ideas, successes and failures at solving business problems with software. Hopefully, it will be a guide for my future-self to be able to look at my past-self’s decisions and improve upon them for my then current-self’s benefit.
Process. I am a firm believer that a well documented process that can be followed repeatedly is the best way to solve any problem. Some problems require time consuming processes, other problems require only a couple of steps. No matter how complex the process, I believe that documenting the process not only allows for a more successful repetition of the process but also provides for being able to improve the process. One of the first endeavors I will take with this blog will be to document the process for which I currently advocate in order to manage enterprise software products. I will borrow heavily from people like Uncle Bob, Eric Evans, Martin Fowler, Dean Leffingwell and many other giants on whose shoulders I am attempting to stand.
That’s the Who, What, When, Where, Why and How of the purpose of this blog. Hopefully, I’ll get into a regular cadence of posting so that I can keep a written history of my experiences.