Thursday, December 12, 2013

The skills of a business architect

Important skills of a business architect includes communication, leadership and analysis. At least was that the result of a workshop in Las Vegas hosted by Jeff Scott. I think that the skills can be applied to software architects also, especially analysis and vision.

What was the best skill? Get'er'done'er.

Saturday, December 07, 2013

Don't measure quality with number of bugs found and fixed

Here is a short summary of a presentation by Nigel Runnels-Moss about why counting the number of found bugs (and fixing them) is not a way to measure the quality. The summary is in Swedish.

Saturday, October 05, 2013

Test your JavaScript

Microsoft provides a way of testing JavaScript libraries automatically. The project is called BrowserSwarm and works lite this:

Whenever you update your code on GitHub BrowserSwarm automatically start a test run. The result is a test report with issues (if any).

Read more at InfoWorld. As mentioned in the article, a very easy way of testing an entire web page is to use Microsoft's modern.IE.

Sunday, September 15, 2013

Ten Ways to Kill An Enterprise Architecture Practice

Ten ways how to not do Enterprise Architecture. I personally like number two, "set no goals":
"Set no goals. Allow individual architects to find their own architecture opportunities and to do them any way they want.   Encourage cowboy architecture."
Too many projects doesn't have a well defined goal, or the goal change during the project's life cycle.

Tuesday, September 10, 2013

R


Investigating a yet one more computer language.

R is a language for statistical computing and graphics, it also features an environment. R can be used to manipulate and display statistical data. Check out the official web or a short introduction at InfoWorld.

Friday, August 02, 2013

When to use a graph database

Interested in graph databases? Here's an article with an example when to use a graph database rather then a traditional relationship database.

After studying graph databases I realize that the choice of an RDBMS that I often do isn't necessarily based on the fact that RDBMS is the best choice. RDBMS is such an integral part of my backbone I don't think of anything else. A very good quote from the article is:

You wouldn't use only one data structure for every type of data in memory, why would you do that just because you're storing the data?
More on the subject:

Wednesday, July 24, 2013

ArchiMate

Here is an article that describes ArchiMate and it's relation to TOGAF.

Saturday, July 20, 2013

The God element

In mid March of 2013 the God particle was confirmed to exist to the joy of many scientists. In software architecture, the God element has been around for years, and in contrast to the particle, the element is fairly easy to spot.

The God element1 is an element with a lot of connections to other objects in the system, the element is in the center of attention and is often called “manager”.




The problem with this design is that the manager is responsible for all the functionality, the manager is the entire system and the other objects merely acts as e.g. data providers. Another problem is that it may lead to a complex system that is difficult to maintain, the manager does too much. Performance, reliability and scalability are key quality attributes that are effected by this type of design.

The solution is to spread out the responsibilities among the elements. Software Systems Architecture1 gives a guideline:
"if you find more than 50% of your system's responsibilities concentrated in less than 25% of your functional elements, you may be heading toward a number of large elements"

1 Nick Rozanski and Eoin Woods, Software System Architecture: Working with Stakeholders Using Viewpoints and Perspectives, Second edition

Saturday, March 23, 2013

A couple of new books

My pile of books is getting larger. In today's mail was a package with the following books:

  • The process of software architecture, Peter Eeles and Peter Cripps
  • The trusted advisor fieldbook, Charles H. Green and Andrea P. Howe
  • The pyramid principle, Barbara Minto
  • Writing winning business proposals, Richard C. Freed, Joseph D. Romano and Shervin Freed
  • Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin
I'm going to start with The pyramid principle, I definitely need to enhance my writing and I hope to get some pointers in writing short, solid and understandable.

Wednesday, March 20, 2013

Software Systems Architecture - revisited

A few weeks ago I started to read the book Software Systems Architecture by Nick Rozanski and Eoin Woods, see earlier blog post. The authors tries to explain the process of software architecture and which tools to use. The book is divided into a number of parts and the second part describes the (getting your hands dirty) working process very well. The chapters in the second part defines which work tasks need to be executed in order produce a well-motivated architecture. Among the tasks are:

  • Identify the concerns and problems the architecture shall solve?
  • Who are the stakeholders? Who will be affected by the product?
  • Create scenarios in order verify requirements and how different architectural solutions will affect the stakeholders.
    • Find missing requirements.
    • Evaluate the architecture proposal.
  • How to create architectural models to visualize the architecture proposal.
  • Summarizing it all, writing the architectural description (AD).

The third part contains a catalog of viewpoints, each viewpoint is well documented. The fourth part contains a catalog of perspectives, equally well documented as the viewpoints. If you haven’t utilized viewpoints or perspectives before then these two parts will be very valuable.

Further reading

Applying Viewpoints and Views to Software Architecture
Developing Architecture Views
Software Architecture Using Viewpoints and Perspectives

Sunday, February 10, 2013

How to create a read only view

In this specific case the server application I'm working with are using a database hosted by SQL Server. The database is designed to be accessed by the server application alone, but there exists situations when other systems also want information from the database, such as status information. In those cases there is a good idea to create a view that other systems may use, and leave the database's tables to the server application. But also, the view should be read only, making it impossible for other parties to change the information. This can be done in number of ways and below I will show two:


Create a read only view

CREATE VIEW CustomersView 
AS 
  SELECT ID, FirstName, LastName FROM Customers
  UNION ALL SELECT 0, '0', '0' WHERE 1=0 

Add a union to the create view statement, the columns in the union must match the columns in the select statement. When the user executes an insert, delete or update statement then is the following error received:

Msg 4406, Level 16, State 1, Line 1
Update or insert of view or function 'CustomersView ' failed because it contains a derived or constant field. 

Create a trigger

First create the view:

CREATE VIEW CustomersView 
AS 
  SELCT ID, FirstName, LastName FROM Customers 

Then create a trigger:

CREATE TRIGGER ReadOnly_CustomersView 
ON 
  CustomersView     
    INSTEAD OF INSERT, UPDATE, DELETE 
AS 
BEGIN     
  RAISERROR( 'CustomersView view is read only.', 16, 1 )     
  ROLLBACK TRANSACTION 
END 

If a user executes an insert, delete or update statement then is the following error received:

Msg 50000, Level 16, State 1, Procedure ReadOnly_CustomersView, Line 7
CustomersView view is read only.
Msg 3609, Level 16, State 1, Line 1 The transaction ended in the trigger. The batch has been aborted.

This is a very nice way to make the view read only. It is also possible to exclude e.g. the UPDATE from the INSTEAD OF list, if the user shall be able to update the view, but not delete or insert rows.

Friday, February 08, 2013

Software Systems Architecture

Received a new book today, Software Systems Architecture by Nick Rozanski and Eoin Woods. The subtitle is "Working with Stakeholders Using Viewpoints and Perspectives". Sounds interesting, I hope to give a review of the book soon.