What’s with all the titles? January 27, 2009Posted by Jeremy in Business, Development Process, Resourcing.
Tags: Architect, Developer, Enterprise Architect, Programmer
add a comment
In today’s IT market buzzwords are definitely the sale point. Microsoft has made an artform out of changing technology names to flashy names. This also occurs in the market for resources. You will hear terms like analyst, programmer analyst, senior developer, team lead, architect, etc when it comes to the development realm. I think that the definition will depend on a company by company basis. I would like to give a brief idea of what I see as the differences.
An analyst’s job is very self explanatory. They do analysis of business systems. The main focus is to outline the business need and document the requirements. In most cases this person is semi-technical but not typically a developer.
This is someone I see as able to write code. They are given a technical specification for a system and they write the necessary logic to make it work. They should be able to write the code and troubleshoot it to make it work. Typically will not create design or architecture models.
Very simply this is an experienced developer. Typically I would say that somewhere in the 5-7 year range will transition developers into this category. Some are able to transition before that. It is primarily based on skillset combined with experience.
Architects titles will change but the general concept is that they are able to see things from a high level structure and can think though the best model for system design. They understand business, software, and systems. The architect will look at things from a long-term viewpoint to build a system that will adjust to meet needs in the future not just current needs. The person would be able to do the job of a developer but would add to that the ability to see things from a high level. This type of person has a mixture of skill and experience. Experience alone is not enough. This is not a skill that can necessarily be learned because it is dependent on ability.
This role is usually a senior developer or architect that has some level of management and mentoring responsibilities. A team lead will NOT always be an architect. Many times you will find that the person will be a developer and not have the skillset of an architect.
The enterprise architect is a higher level architect. A software/system architect would tend to focus on systems, the enterprise architect would focus on the entire enterprises architecture. This would include software, networks, external connections, etc. They will look at the overall architecture of the entire business system.
There is definitely a difference in the roles that are played. Also, there is huge difference between the titles from company to company. In some places people can move into architecture roles purely through seniority. If you are trying to hire people don’t just look at titles look at what they have done. I hope that this brief outline will give you a better idea of what you are looking for.
Simplifying Organizations November 10, 2008Posted by Jeremy in Business, Business Solutions, Development Process, Efficiency Process, Efficient Technologies.
Tags: Architecture, Business Efficiency, Business Focus, Business Systems, Framework, Technology
1 comment so far
I recently finished reading a book called Simple Architectures for Complex Enterprises by Roger Sessions. The book is about building architectures that are simple instead of overly complicated.
Organizations and business models are very complicated. Add on regulation, best practices, trade secrets, etc and the business processes can be very difficult to utilize. Many times these complicated systems cause issues for the businesses because employees can get lost in the details. It also can make it extremely difficult to train new employees. This causes a real problem should one of the employees go on long-term disability, maternity leave, or worse yet to the competitor. Many times it is not a scenario where a temporary or new employee can just step right in and take over.
The other issue is that if the employee were to forget a step or not do it correctly it can really cause issues for your business. Sometimes it may be as simple as having to fix the mistake but other times it could result in regulatory or even legal issues.
All of the issues raised above and many more cause the need for frameworks. A framework is structure that is put in place in order to standardize and simplify a process or set of processes. In many organizations, there are many frameworks in place: network frameworks, software frameworks, process frameworks, etc. By utilizing properly designed frameworks employees should be able to do their jobs more quickly and efficiently in a very standardized way. This will make the organization much more efficient overall.
Many organizations have become very framework adverse. This is due to the fact that they have invested a lot of money and time into frameworks and not seen the corresponding results. Many times this is due to the fact that the framework has become way too complicated. The book I described earlier has the following quote in it:
The paradox about complexity is that it is simple to make systems complex; it is complex to make systems simple. Many people think that it takes a lot of talent to create a highly complicated architecture. That isn’t true. It takes a lot of talent to take complicated ideas and realize them in a simple architecture.
I believe that this is absolutely true. In many cases the frameworks try to handle the complexity of all the business without ever taking into account that the point is make it simpler and more efficient to use. Instead they have only focused on handling all the business complexity in a single place. In the end, the framework has cost the business quite a bit of money and has not made them more efficient and possibly made it harder to get things done.
In order to make frameworks really help businesses they must be simple to use. For this to happen the person creating them must focus on simplicity while also solving the problem. This can be a very difficult thing to do. Another quote from Session’s book says:
Anybody can create a complex architecture. It takes no skill at all. Architectures naturally seek the maximum possible level of complexity all on their own.
It goes on to say:
The observation that architecture are naturally attracted to complexity is actually predicted by physics – in particular, the law of entropy.
All of this to say that it is natural for frameworks to become more complicated and chaotic if someone doesn’t focus on keeping them reigned in. This is the job of the architect. It is by far the hardest job that architect has. As stated earlier, it is quite complicated to keep the frameworks simple to use.
I hope that this article wasn’t too techie or high level. I found Mr. Sessions’ book to be very interesting and should serve as a reminder to follow the KISS theory when building frameworks. Frameworks can have a significant impact on organizations in terms of business efficiency. On the other hand, if not properly handled they can actually have the opposite effect or making businesses less efficient.
Do you have frameworks in place to make yourself more efficient? If so, can you make them simpler? If you don’t have them, are there ways to create them to make your business simpler?
Let me know if I can help you with creation or simplification of frameworks.
Technical People vs. Business People September 11, 2008Posted by Jeremy in Business Solutions, Development Process.
Tags: Analysis, Business Process, Business Solutions, Development Process, Solution Architect
add a comment
I have heard and seen so many stories that say “the IS department at our company can never get anything done” or “the users don’t know what they need”. It is at epidemic stage at many businesses. At many companies it is an us vs. them idea. This is extremely sad due to the promise that technology can hold for optimizing the work and business environment.
Why does this happen? I would say the biggest reasons are: communication, time, and understanding. Those three items are a triangle. In many businesses the timeline is set long before anyone spends any time fully outlining the problem. So by the time that the business unit and IT get together they are already behind the “eight-ball”. So they limit the communications to a few meetings to describe what the business is looking for. Many times the business unit doesn’t have the time or the training to create specifications so they leave that to the IT staff. The IT staff doesn’t have the business training to fully understand what they are being told and what the business unit is trying to do. So by intermixing lack of time, lack of communication, and lack of understanding the specifications are not complete and quite possibly not correct. Since the business unit does not completely understand specifications they may think that it is complete and correct.
Once into the project, the business users are now able to see what is coming together and find that it is not what they need or requested. At this point, there are discussions of what needs to be changed.
When that happens, there are two routes that are usually pursued. First, the technical people will have a problem with the change because their solution is “to spec” meaning that it meets the written specifications. This causes there to be discussions of the specifications being incorrect and many times finger-pointing ensues. The second possibility is that somebody will just say “fine, we’ll change it” without altering the specifications or understanding the complete scope of the change. In this scenario, many times changes start to be made without control which causes more issues and more fixes. This can turn into the “black hole” project.
So what do we do?
Both sides of the equation need to understand that there is a knowledge gap. The business unit will not typically understand what the technical people are asking/meaning because they are not trained how to develop solutions or even how to do analysis. The IT staff will not typically understand what the business is asking for and why they are asking for it. You really need to have one or more people that really understand both sides of the game. There are a few solutions that I can think of
In some cases, the solution is a business analyst. This is a good solution as long as the person understands both sides. This is a good solution as long as they can understand both sides. This can be difficult because if you bring an outside analyst who understands analysis they may not understand the business or IT. If you use and internal business user who really understands the business may have a tough time communicating it to technical people and may not understand how to do the analysis. If you use a technical person, some of them may not be good with the business and/or analysis.
Education of resources
Some companies will have both sets of resources to spend time with each other to understand what each other does. They may also spend the time and money to help both sides understand how to do analysis. The developers will spend time learning how the business runs and the business will spend time learning how the systems will operate. This can be a great solution. It can also be time and money intensive.
This is the term that I use for someone who has the education and ability to do analysis, design and development of the system. The advantage to someone like this is that they have the ability to work with the business users to do the analysis. The same person has the ability to architect and design the solution that will solve the problem. They may even be involved in the development effort. The advantage you get with someone like this is that less will get lost in translation. The only thing that the solution architect will need to do is spend time to learn the business process. This can be done by having that person spend time with business users or maybe even train and allow them to do the job. This is a process called shadowing.
In many cases, the solution architect has the ability, knowledge, and experience that comes with doing this process many times so they know what they are looking for and really how to learn from what they are watching. They then will have the ability to analyze and document the process. From that they would come up with a proposed solution and design and architect it. This will allow the developers to understand what is being built from a technical aspect. This allows one person to translate between business and technical people.
As I said, it is sad to me that so many IT projects have issues due to timelines, miscommunication, and misunderstandings. If companies and people will begin to put people in place that can be the “translator” between business and technical jargon, I think more companies will realize the vast improvements that technology can bring. It really shouldn’t be “us vs. them” it should be “how do we solve this issue?”. Honestly, in some cases they speak different languages so in turn they need a “translator”.
Build vs. Buy Revisited July 11, 2008Posted by Jeremy in Development Process.
Tags: build, buy, development, Development Process, Refocus, software
1 comment so far
I wrote the original version of “Build vs. Buy” some time ago and realized that I it needed some work after rereadng it.
I believe that the information that I provided for purchasing a solution still holds true. Much of the problem with purchasing a solution revolves around the fact that in many cases you will need to mold your business to fit the software.
Now, I will qualify that there are definitely solutions out there that can be customized to meet your needs by the software company. In this scenario you will need to work with the vendor to find out the customization capabilities of the software. At this point it becomes much more like outsourced build.
This method is still a viable option but I believe that it takes a significant investment in order to successfully acheive the desired results. There are actually a few problems that will arise (on top of the previous list):
Lack of internal resources
Many businesses simply do not have internal resources to be able to handle the life cycle of a new development project. In many cases, they also may not have the resources to help them determine what resources they need. In is a catch-22 situation. In order to staff a new development project you really need someone who has experience in new development projects. It can also be quite difficult to find the people with the right skillsets with out someone to validate that they actually have the skillsets. This can be a very difficult situation and it gets many companies into trouble.
Lack of internal process
For many businesses who have not done new development or it has been a long time, they do not have processes in places to work through the development lifecycle. This takes considerable effort and thought to implement. Although many businesses choose not to do it, it is extremely important. Without the proper process in place to do analysis, design, development, and testing the project can be drastically delayed if not fail.
Lack of IT Resources
In today’s IT market, it can be very difficult to find the resources that you need to complete a development project. In many areas of the United States there are IT shortages. This means that although you have good intentions of hiring a senior level developer to help, you may have a difficult time filling that position (either as a full-time employee or even a contractor).
Cost of IT Resources
Because of the demand for IT resources, the cost to get good resources is definitely on the rise. Based on estimates, that is not going to change in the foreseeable future.
Based on the reasons above in the internal build, I personally believe that outsourced development is going to continue to grow.
**Please understand outsourced development and offshore development can be different things. Outsourced simply means someone else is doing it, preferrably a software consulting business. It can be either domestic or overseas.
Ability to retain skilled resources
An advantage that outsourced companies have is that all they do is develop software so in many cases can afford to keep more skilled, experienced, and expensive people on staff. For many businesses, the price to retain those resources is simply too much. On the other hand, if they can pay the firm to use the resources and build the solution and then they are done, it can be a viable option.
In most cases experienced, skilled resources can also deliver the project in a shorter timeframe with less time required for testing and rework. This is because the resources involved have typically completed many projects before and they have worked out their process.
Another advantage that outsourced build companies can have is the use of reusable components. Because they are writing software all the time, they are running into a lot of scenarios where they can build components that can be reused. Examples may include: data access components, logging components, document management, etc. This will typically reduce the expense and timeframe of a project because they are pre-developed and pre-tested.
This post definitely came off sounded biased toward the outsourced development option and quite honestly I think it is for a good reason. I think in many cases outsourced development shops are better positioned with resources, experience, and their development processes to complete projects more efficiently than many businesses are. This is mainly because most businesses are not development shops. It is not their focus. It is no different that outsourcing your printing, marketing, cleaning, lawn care, or whatever. In most cases the companies that focus on a specific task can acheive the desired result cheaper, faster, and easier. This is simply due to having the necessary resources and the necessary experience.
I hope that helps.
Build vs. Buy July 10, 2008Posted by Jeremy in Development Process.
Tags: build, buy, development, Refocus, software
add a comment
**8/18/2008: I have added an update to this article: Build Vs. Buy Revisited
This is an article that I wrote some time ago. I hope that it helps.
Should I build or buy my software solution? It is a question that has divided IT and management at businesses for years. The question has people standing on both sides of the fence and many who sit right in the middle. Most companies at some point have to make the decision.
This is not a simple decision to make, but it is much easier if you can understand the factors that go into the decision. Each project is unique and will require some thought to make the decision that best suits your company’s needs.
Turn-Key Solution – Solutions that you can take out of the package, install, and begin using.
Buy – Purchase a turn-key solution from a third party vendor to meet your needs. This process usually entails finding vendors, interviewing them, watching demonstrations of their products and wading through the promises of features.
Internal Custom Build – Hire development resources that can build and implement a solution based on your customized needs. This process can involve either hiring resources directly as full-time employees or sub-contracting resources. Directly employing the resources can include searching through resumes, interviewing candidates, offering jobs, and all of the human resources issues that go along with employment. Sub-contracting can be every bit as challenging due to having to find reputable sub-contractors or contracting companies to provide resources.
Outsourced Custom Build – Employing a third party to build and implement a customized solution to suit your needs. Much of this is very similar to the buy option. You will need to find and interview vendors and then sort through information to determine if they will meet your needs.
Questions about your needs
In order to determine which solution best fits your needs you will need to answer a few questions about your company’s needs. A list of the questions to begin your decision making:
What is our timeframe?
What is our budget?
How much customization is necessary? (Now and in the future)
How much oversight do we need to have?
How would we like to deal with system upgrades?
Can we create detailed specifications of how our business runs?
Do we need control over the software?
Obviously, this is a subset of the questions that you would need to ask in order to define which solution but they are quite important ones to consider. Each one will help make the determination easier.
What should I do?
I can’t answer this question for you but I can assist you. Some of the key pros and cons for each type of solution include:
Pros for Buy:
Usually can have the software running in short timeframe
Lower initial cost
No need for development staff
Support typically provided by third-party
Cons for Buy:
Lack of customization to your needs
Updates are on third party’s schedule and priority
Typically no onsite support
Your prioritized against other client’s needs
Pros for Internal Build:
Solution is customized to your needs
Updates on your priority and schedule
Cons for Internal Build:
Need for development staff
Hiring technical staff can be difficult
Longer deployment timeframe than buy
Pros for Outsourced Build:
Solution is customized to your needs
Possibly on-site support
Typically updates based on your priority and schedule
No HR or hiring issues
Cons for Outsourced Build:
Typically highest cost
May compete with other client’s for resources
Longer deployment timeframe than buy
Dependence on third-party
The buy vs. build decision is a decision that causes headaches for many companies. This is due to the fact that there are many competing interests that affect the decision. Another thing that makes this decision difficult is that each project has different factors to consider. This means that each project will require that you analyze each project and make the decision that best suits the project’s unique needs.
It is my hope that this article can assist you in at least starting the decision-making process in the future.”