Entries for 'timbryce'

 

The design of major systems need not be a complicated process couched in a cryptic vocabulary using seemingly esoteric techniques. While the state of the art in programming has undergone considerable changes over the last half century, little progress has been made in the area of systems which has stagnated due to the lack of standards and the heavy emphasis on programming.

Nonetheless, it's a new year, and time to go back to work. January is when we reset the statistics, brace for a new year, and try to prove ourselves once again. Some people have trouble getting back into the swing of work after the holidays; they've probably slept too much, partied too much, and ate way too much, which explains the five-to-eight pounds they've put on. This is why dieting and temperance are among the top New Year's resolutions. Regardless, they are having trouble focusing on their work.

Quality and service used to be considered paramount in this country. If it wasn't just right, you were expected to do it over again until you got it right. We cared about what we produced because it was a reflection of our personal character and integrity. But somewhere along the line we lost our way and craftsmanship has fallen by the wayside. Why? Probably because we no longer care.

Are we really trying to promote teamwork or is this nothing more than the latest corporate fad that is being implemented more for public relations than anything else? Let's hope for the former and not the latter. Teamwork is a powerful concept, particularly when there is anything of substance to be done.

Estimating is one of the most controversial subjects in project management. There are some people who have turned the subject into a cryptic science involving esoteric techniques. Estimating is simply the process used to determine the amount of effort and cost required to implement a project, in part or in full. It is important to acknowledge that...

The point is, no amount of elegant programming can solve a system problem without someone who understands the overall system architecture, someone who understands how the business works. Attacking systems development without such orchestration, such as one program at a time, will not produce the desired results. That would be like trying to build a bridge without a set of blueprints; it would probably be disjointed and one end would likely not connect with the other in the middle. 

Watching the speed by which Information Technology (I.T.) has changed over the last forty years has been amazing. Hardly a day goes by without some new twist or invention. In particular, my interest is in how I.T. can be applied to support the systems needed to operate a business, such as for manufacturing, inventory, order processing, customer service, accounting, human resources, and much more. I have seen a lot during the last four decades, perhaps too much.

It appears to me people still have trouble defining information requirements and, as such, they are at a loss as to how to build total systems. Thereby, they are content building either a single business process or a program. Therefore, here is the conceptual foundation for all system design. Information Driven Design begins with a simple concept...

While others are moving forward introducing new banking products, the Americans find themselves in the role of constantly fighting fires. You cannot move forward until you put your house in order by bringing standard practices and discipline into your work effort. This is what happens when you treat system design as an art form, as opposed to a science.

In addition to the fundamental duties and responsibilities of an employee, it is not uncommon for workers to misunderstand their various project assignments. Consequently time and money is lost as employees try to delineate their responsibilities, including their relationship with co-workers.

There are several interpretations of Business Process Design, which is concerned with devising a cost-effective approach for the various tasks to be performed in a business. Here is mine which has worked effectively for me for several years. It's not a matter of what tools I use, but rather understanding the principles behind the design process itself.

In a recent Information Technology discussion group I am involved with, someone posed the question, "What is complexity?" I was surprised by the question as I thought it was understood what complexity was all about. Evidently not. The person posing the question was primarily concerned with complexity in system design...

Whenever I mention I am in the "Systems" business, people generally look at me befuddled, smile, and shake their heads. I can tell they haven't got a clue what I am talking about. Many assume it has something to do with computers, and those in the technology sector assume I am referring to software. Frankly, no.

 They took a software approach for designing MIDAS as opposed to a system approach. For example, they probably created a data base quickly, then tried to figure how to get data in and out of it. I would suspect the program source code was well written, probably using "Agile" techniques, but the fact remains none of it was designed to work in a concerted manner.

I have come to realize the practitioners in this industry suffer from acute myopia regarding their work. Programmers tend to believe their part of the puzzle is the most important, as do business process analysts, data base analysts, network analysts, project managers, enterprise analysts, etc.