Showing posts with label Architecture. Show all posts
Showing posts with label Architecture. Show all posts

Tuesday, March 31, 2015

Implementing and Delivering Software Solutions

Every software development project I have worked on since I started my career in 1999 has faced challenges. The types and complexity of the challenges have varied from project to project. Our goal as IT professionals (engineers, architects, analysts) is to overcome these challenges and deliver a solution. For some IT professionals the challenges become a crutch, an excuse to walk away. For others the desire to conquer these challenges becomes the reason we wake up everyday and make things happen.

Monday, October 17, 2011

Focusing on Business Continuity, Scalability and High Availability

Business is 24/7 and customers want access to your product at their convenience. As a developer and designer of many public facing applications, I find this is one of the most overlooked concepts when businesses are looking to improve their existing applications.

We are in a world where free, social networking applications perform above and beyond most "enterprise" level applications. Our business customers are experiencing this availability and performance and they are looking to internal IT staff and infrastructure teams to step things up. If you are part of a company's internal IT staff, you should understand how some of the top social sites are managing PetaBytes of data and millions of concurrent online users. The actual capacity numbers may not match up to your work environment but an important quality of scalability is being able to scale up as well as scale down.

Just some thoughts of what is on the horizon for professional IT staffers who are considering on being relevant as "enterprises" embrace the lessons learned by many of the top technology companies.

Tuesday, May 10, 2011

Discussing Technical Debt

There are a lot of software developers that discuss Technical Debt. Martin Fowler has a nice post on Technical Debt and I also encountered the term while checking out the Sonar project a little while ago. Technical Debt is something that I feel businesses and developers do not understand in its entirety and for good reasons. When a developer is tasked with making a decision about a functional implementation, options are sometimes available. One implementation can be done by a date d and a possible second implementation can be done by a date d + n. The ideal developer response is to propose all solutions and dates and let the business decide on a path to follow. It is key that the developer provides the pros and cons of all proposed solutions. Most of the time, developers can even eliminate a solution because of governing software development standards or by understanding the pitfalls of a solution which may impede maintenance or functionality in the future. In many cases, developers may not recognize the availability of other options or understand the pitfalls of a solution. In other cases, the business settles on the fastest solution. These scenarios may introduce Technical Debt.

In the enterprise environment, the introduction of Technical Debt may occur quite frequently, that really depends on quite a few environmental factors. So how do we understand and measure Technical Debt? Sonar is definitely a great tool that can help identify code in the red. Technical talent definitely has an incredible impact on Technical Debt. Having high quality developers with experience is very important when identifying and reducing Technical Debt. Managing an inventory or repository of software artifacts that are well documented can provide insight to relevant, proven and performing code. As developers, managers and IT executives we have to recognize and identify where we can alleviate debt by determining how to move forward with the relevant, performing code while leaving behind under-performing or costly code bases.

Technical Debt is not necessarily a platform or language, so moving to Ruby from Java or to Java from C# is not an answer to fix the debt problem. In some cases, changing languages or platforms is like a foreclosure or declaring bankruptcy. You get to put your past behind you, (well kind-of), but if you continue to make poor development decisions you will eventually end up over your head and in the red. Focusing on understanding Technical Debt and putting measures in place to reduce debt is really the way to move forward.

Wednesday, January 05, 2011

Availability != Scalability != Performance

Availability - the degree to which a system is responsive or in a state in which it is expected to be in

Scalability - property of a system to manage increased load as expected or the capability to be expanded to handle increased load

Performance - the speed or measure of the completion of a unit of work

Just some thoughts I had today about computer systems and what is important to end users. Redundancy should also be in place, but maybe it's not a concern for end users.